Paper Discussion 14a: Don’t Talk Unless I Say So! Securing the Internet of Things With Default-Off Networking

[mjhegarty]

Please add your feedback and reviews below. @marcusgillesyoung, Marcus Young, Critical: I agree with your critique of how they don't talk about the path to adoption for their system at all. @searri, Rick Shear, Critical: Good point about the assumption of the router being safe. I feel like for a home network device especially that is not an assumption this paper should make. @pcodes, Pat Cody, Critical: Can this scale in terms of human cost? : I think that the inclusion of groups and wildcards will definitely help the system scale assuming they have relatively simple UIs for adding something like a smart light to a group. @grahamschock, Graham Schock, Critical: I agree that there should have been some sort of human usage analysis done in the paper, not just a couple of pointless latency charts. @s-hanna15 Sam Hanna, Critical: I agree that users will probably just leave devices on as simple of setting as possible which would open up vulnerabilities. @rachellkm, Rachell Kim, Critical: How will devices that move around and aren't always in the same place fit into network?

Shared sentiments

• The gateway cannot be assumed to be secure.
• Paper lacked information about how it fared in the hands of end users.
• End users can't be trusted to not make mistakes in securing system.
• Based on English language would it scale to other languages?(Graham and Reese)

[themarcusyoung]

Reviewer: Marcus Young Review Type: Critical

Problem Being Solved

IoT devices have tremendous security vulnerabilities in our computing networks. Unlike traditional networked applications, IoT applications and devices serve narrowly defined purposes, and do not require access to all services in the network. Bark exploits this fact by specifying and enforcing minimal access permissions in IoT networks. With Bark, a user can explicitly specify enforceable rules for IoT application protocols. This essentially allows users to secure their IoT devices by implementing access control policies such as “Let the lights see the luminosity of the bedroom sensor at any time”.

Main Contributions This paper has three main contributions. First, Bark proposes an argument for a default-off communication model for the IoT to defend devices from network attacks and vice versa. Second, once the communication model for an IoT setup is default-off, users can use the Bark specification language to whitelist access to IoT applications. Lastly, they propose a non-network or user-in-the-loop context to express network access control polices using a practical application of two-factor authentication.

Questions

1. If default-off is a better, safer IoT communication model than default-on, why is the default-on model the current standard for IoT devices? Is the default-on model economically cheaper and easier to maintain for IoT manufacturers?
2. What are potential vulnerabilities for specifying access permissions with Bark? What would stop someone from whitelisting themselves, or other malicious devices into the system?

Critiques • Although the paper provides a blueprint for implementing a default-off IoT communication and using Bark to enforce minimal access permissions, it does not identify the obstacles or the path to adopting this new, safer default-off communication protocol. I would have preferred if they identified the incentives to why the current model is default-on, and how we can influence manufacturers to switch to a default-off model. • For some consumers, IoT devices will seem less appealing if they are default-off simply because a default-off model is more user demanding. The user must whitelist access to IoT applications for virtually every action of an individual IoT device and some might not see the added security as worth it. Many users might find this process tedious or even difficult.

[searri]

Reviewer: Rick Sear Review Type: Critical

Problem being solved

We've already read a lot in this class about how vulnerable IoT devices are to a plethora of security risks. This paper attempts to improve the issue of network security across the board.

Important contributions

The paper's main point is that IoT devices shouldn't be connected to the internet by default. This simple principle of only connecting when necessary is possible because of the limited way IoT devices talk to the web, and can have significant security benefits like preventing devices from being used in botnets even if they are compromised. The paper also introduces Bark, a system for specifying conditions when a device should be connected.

Questions

• Section 8 goes into some related areas that could be affected by a widespread adoption of Bark. Are there existing IoT systems that would simply not work with Bark? Is this too much of a barrier for people to overcome?
• Rather than having the Bark enforcer in an internet gateway device, are there situations when Bark could be deployed directly on an IoT device to intelligently turn its connectivity on and off? (Maybe this isn't even worth considering, if there aren't enough circumstances this would work)
• I liked the discussion on Bark's overhead, but I'm curious if there are other factors that play into its latency besides number of rules. For example, if I specify really complicated when conditions, does that slow down the system noticeably?

Critiques

• The paper is very upfront that it assumes network gateways are trusted. This was fine until I saw that Bark as an enforcement mechanism exists entirely in the gateway. That makes the "trusted gateway" assumption pretty big, moving towards the "we assume our security enforcer is secure, therefore our system is secure" issue. I would like to see exploration of either security for gateways or alternative places for Bark to exist in the system architecture.
• The paper has a lot of examples of ways their system can be used. However, I would like to have seen a little more testing of the security attack side of things, since this is the main problem Bark is trying to solve. Specifically, it would be nice to see (similar to the Honeypot paper) how many attempted attacks there were. Does this system accomplish its goal? The paper makes a lot of assertions about what Bark will and can do, but there's not much in the way of experimentation to back this up.

[AkinoriKahata]

Reviewer: Akinori Kahata Review type: Critical

1. The problem being solved.
   • In our society, the number of IoT devices is increased rapidly, and these devices make our life much better, such as many smart devices in homes. However, these devices are vulnerable to cyberattacks, and many cyber incidents happened in the real world, such as Mirai botnet. Then, the researchers challenged to develop useful security language “Bark” for IoT security, which enables IoT devices to be default off and whitelist type communications.
2. The main contributions.
   • The suggested security language bark enables IoT devices to be default-off by using whitelist type communication, which is very helpful for IoT devices. Blacklist type of security measure needs to be always updated, and reduce the vulnerability to zero is impossible. Because the structure of bark language is simple, and users can write rules flexible, such as who can connect to a specified device, and this mechanism does not make critical latencies.
3. Questions.
   • This language and system can be implemented gateways and edge devices easily? I think the most important point of security method for the IoT devices is easy implementation.
4. Critiques.
   • Although the researchers assume that gateway can be trusted, in my understanding, the most critical point of this scheme is security of gateway. Then, I think the researchers should discuss the security of gateways with this mechanism.
   • The implementation cost is very important point for consumer IoT systems. The configuration for bark, especially Wildcard configuration, are looks complicated. I think simple two types of authentication or other method is still safe and simple.

[pcodes]

Reviewer: Pat Cody Review Type: Critical

Problem Being Solved

IoT devices are useful because they're on the internet, but that also makes them vulnerable. Due to the optimization for convenience over security, many are poorly secured. Because the nature of IoT devices is being out of the way, an intrusion might not even be detected. This "always-on" connection with these devices, even when not being used, is unnecessary and switching to "default off" would solve many of the identified problems.

Main Contributions

This paper provides a case study to demonstrate the benefits of using a "default off" means of internet access, where each device must have connections be explicitly approved. To accomplish this, they implement BARK, a language interpreter to convert sentences into security policies. In doing so, it abstracts away the technical complexities and allows users to create policies through question words (who, what, when, where, etc).

Questions

• How effectively does this scale, from a human-cost perspective? As I add more and more devices, how difficult/inconvenient would it be to have to specify security for everything?
• Is there an incentive for this "default off" behavior to be baked into IoT devices?
• While I appreciate the benefits of caching Bark policies, how would applications function without reliable internet? Maybe these would be bluetooth based, but this constraint with an unreliable network and how it pertains to liveness feels like they're overlooking larger problems that would occur.

Critiques

• Security is only effective if it's used- it would be interesting to see a user study examining whether people find this project (and what it's preaching) effective/informative, and whether they would actually want that functionality in their home.
• Wished they had discussed more tradeoffs of having a semantic-based system (if we're abstracting away all programming, what features are we losing?)

[grahamschock]

Reviewer: Graham Schock Review Type: Critical

Main Problems As internet of things devices become more and more prominent the risk also increases. One of the largest security flaws of these devices is the network they use to communicate with each other. This is mainly due to the fact that the manufacturers prioritize convenience over security and they operate and sell in such a low profit margin market.

Main Contributions This paper proposes and gives an implementation for a default off communication protocol. This paper defines Bark which is a policy language which enforces minimalist access permissions on a network. Bark also uses natural language to communicate it's policy which makes it more user friendly and convenient.

Questions

1. It looks like the bark specification language relies a lot on English grammar of having a subject and a predicate and the relation between those two. I wonder how this would translate into different languages for a different user base and if it would be as clear and presentable to said users. For example polish uses capitalization and casing on subjects to show their relation to certain predicates.

2. What are the other drawbacks to using a semantic language like bark? Is the only drawback latency as their is more logic that is needed to interpret packets?

3. The paper says that IoT devices/applications do not require all services in the network because they have narrowly defined applications. What services does a traditional device use that an IoT devices would not need.

Critiques

1. It would have been more accurate and fair if they showed the drawbacks of having a default off policy? Is it easier for this system to have bugs etc.

2. The paper just says that having Bark increases usability. It would be nice to have some sort of quantitative data like a survey to back up this claim.

[mralexjacobson]

Reviewer: Alex Jacobson Review Type: Critical

Summary of problem being solved:

Iot devices have predictable network usage. By exploiting that fact and closing them off to the outside world, except where explicitly authorized, security can be improved.

Main contributions:

This concept can be achieved by assigning different terms that are familiar to end users to different parts of the IOT equation. Devices and applications are the “who”. Specific services that “whos” are exposed to are referred to as “what”. The first gateway to the outside world a “who” is connected to is known as a “where”. “How” refers to a command or operation, and “when” refers to boolean conditions such as time. These can be further applied to subjects (who, where), objects (who, where, when), actions(a “how” that defines how subject can interact with object), and conditions. The user can manage these permissions so that, for example, members of a household can only unlock the smart lock when they are at home.

Questions:

1) As an owner, would I be able to override permissions from afar? For example, let’s say I have the system set up such that only people at home can control the lights (we don’t want the little brothers and sisters to mess with us when they are out). Then I go on vacation and want to be able to turn my lights on to deter potential thieves, but I do not have permission to turn the lights on when I am not home. Can I simply log in and change the permissions? Or do I need to be on the same wifi network as the devices I am trying to modify?

2) The authors achieved their design by setting up a policy server. How would an end user who may not know how to set up such a server take advantage of BARK’s security benefits?

3) When using BARK with existing IOT devices, how can we ensure that there are no side-channels? What if the existing device has a side channel already? Can we get rid of that side channel?

Critiques:

• The systems design, especially with its tuples and boolean expressions reminds me of databases(mySQL) and how they ensure data integrity.

• The system assumes that IOT devices, apps, and remote servers communicate exclusively through gateways, and there are no side-channels. This seems to be a rather bold assumption. We must verify and be certain there are no side-channels.

[albero94]

Reviewer: Alvaro Albero Review Type: Skim

Problem Domain

Smart devices bring us lots of benefits but recent attacks have shown that they are a security vulnerability too. They are easy to compromise and this compromise goes undetected, mainly because they are low margin products that do not follow best practices and we only interact infrequently. Many of these attacks are performed using communication protocols that the devices are exposing and are not secure.

Main Contributions

The authors first argue that many of the attacks could have been avoided by following a default-off policy in all communications of an IoT device. These devices have a very specific task so they should just explicitly and finely enable the require communications to perform those tasks.

They also propose Bark, an IoT access control policy specification language that is expressive, precise and presentable to the user. Bark phrases access control policies in terms of what, who, when, where and how and phrases with a subject, object, action and conditions. It then transforms these phrases into transparently enforceable rules. They implement Bark for Wi-Fi/IP and Bluetooth Low Energy networks and evaluate its efficacy.

[hjaensch7]

Reviewer: Henry Jaensch Review Type: Skim

Problem Being Solved

Iot devices have been rapidly developed without much consideration of security. Many devices have been connected to the internet without proper security protocols or restrictions. Additionally Iot devices typically lack a way to tell if they have been compromised. This undetectable security vulnerability paired with almost unlimited network access is what this paper is trying to address.

Main Contributions

This paper provides a system for expressing Iot device access and a policy server to enforce it. This system is called Bark and it uses natural language to express permissions. This paper also suggests the notion of default-off for devices, allowing minimal permissions necessary to have the Iot device function properly. The notion of default-off with whitelisted communication is useful for improving the security of Iot devices.

[ericwendt]

Reviewer: Eric Wendt Review Type: Skim

Problem being solved This paper argues that IoT devices have many security vulnerabilities, and that communication to them should be disconnected by default. Any connections made should be approved by the user to minimize break-ins.

Contributions One notable contribution to this paper is their description of Bark. The description starts off by listing prevalent characteristics of IoT devices. Who- talks about the nature of the device including MAC address and IP. What- refers to the services offered by the device, typically denoted by UUID for Bluetooth devices. Where- refers to the physical location of the devices. How- refers to the communication mechanisms to talk to the devices. When- refers to time restrictions and when commands need to be executed.

[s-hanna15]

Reviewer: Sam Hanna Review Type: Critical

Problem Being Solved: This paper talked about network security on IoT devices, specifically the principles of default-off and white-listing. IoT devices have a more specific focus than traditional networked devices so a default-off principle could stop common attacks and help to stop the spread of things like botnets.

Important Areas: This paper focuses on the principles of default-off and whitelisting for network security of IoT devices. To do this they propose Bark, a system that combines types (who, what, where, when) with rules (subjects, objects, conditions) in order to give permissions to when the device can communicate with the network.

Questions:

1. Even simple things like changing default passwords aren't being done now if the user has to set up these types and rules, what is stopping them from using a default-on similar to using a default password?
2. They talk a lot about allowing a user to change things “while at home”, how do they determine who is at home? It seems like it would be fairly easy to trick it into believing you are at home and thus gaining normal access
3. Do all of the devices on the home network automatically get enrolled in this? If there is a DoS attack on bark does that mean that all IoT devices attached will also be unable to make any requests?

Critiques:

1. They don’t do any testing on security measures to ensure they are secure; this would have been helpful to see if it actually worked or is just a good idea in theory.
2. They say they don’t have a focus on performance, but performance is something that is very important to IoT devices and the increasing time it was taking with higher amounts of data is a concern. It would be nice if they had addressed that a little more.
3. The idea seems to be to make it easier for people to understand whitelisting and default-off to make sure they can enable it for their own devices, and while I think this is a good idea, I do see how this can still be complicated for the everyday person. They still have to understand the general grammar structure of it and make the right decisions on who to let in when.

[lrshpak]

Reviewer: Lily Shpak Review Type: Skim

Problem Being Solved

The authors of this paper want to prevent IoT devices from communicating with other devices without the user's knowledge. IoT devices are vulnerable because they are easy to attack and attacks can go unnoticed. These devices are not designed to be super secure, they are designed to be convenient for the user.

Main Contributions

The authors propose Bark, which is a specification that will monitor who the device communicates with. Bark enforces the default-off policy, meaning that the devices will not communicate with another device unless it is authorized to.

[rachellkm]

Reviewer: Rachell Kim Review Type: Critical

Problem Being Solved:

Although IoT devices serve to improve and enhance our daily lives, many devices carry vulnerabilities that place the security of its users at risk. To mitigate this issue, the authors propose a new protocol that would allow users to explicitly control permissions and enable network communications through configuration rather than having a default-on policy.

Main Contributions:

The authors of this paper propose a default-off policy for network communications in IoT devices. Moreover, in conjunction with default-off, the authors propose a policy specification language called Bark, which gives users the ability to exercise access control and enforce whitelists for their IoT applications and devices.

Questions:

1. Bark is meant to give users flexibility and fine grained control over the access policies of their devices, but how do users know when Bark is unable to pick up on certain semantics? How do they intend to instruct users on how to construct these commands?
2. How does this (default off and configuration through Bark) work out for IoT devices that are not stationary and connection to the network is not always the same?

Critique:

1. It sounds like a fairly simple but good idea to allow users to frequently configure and change access policy for their devices to prevent trivial network attacks, but it also seems like a bit of an oversimplification to assume that there will be absolutely zero new vulnerabilities with this implementation and to not consider the possibilities of other weaknesses.
2. They propose two-factor authentication or secondary attestation as a means to protect users against an over-permissioned cloud, but this also seems to rely on the user to be able to differentiate a malicious command versus a trusted notification from the device’s service providers. Many users are often unable to stop themselves from clicking on malicious emails, so I wonder exactly how much more security this implementation provides in the real world.

[reesealanj]

Reviewer: Reese Jones Review Type: Critical

Problem Being Solved: As we have discussed many times within the class, IoT devices are more susceptible to attacks due to the fact that the majority of them operate with default-on networking, leaving many ports open to attack. This paper addresses that issue and discusses the benefits of default-off networking and opening only the networking necessary to function normally.

Main Contributions: The largest contribution from the paper is the Bark system that they proposed for using natural language to express access controls for systems. The system allows for maintaining as few open permissions as possible in an easy and understandable manner.

Questions:

1. Is there a way to potentially gain access to a bark system from offsite and appear as though you are in the home? That seems like a key component of the system that isn't discussed well enough.
2. In their discussion of the threat model when they give the HVAC example, they say only the thermostat, cloud server, and app on a homeowner's phone are trusted but how can they ensure the app being used is always on the homeowner's phone and now logged out and logged into on another device?
3. How does the system function in places with imperfect internet?

Critiques:

1. The system is built around English grammar but there are (without a doubt) a large number of IoT devices not being used in English speaking homes, and the fact that the paper doesn't go into how the bark system could be translated into other languages is a large shortcoming.
2. The description of the bark system routinely describes editing things while "at home" but they don't discuss how that is determined/how accurate their measurement system is.
3. The fact that the authors don't go into how well this is used in a practical home (such as testing it in a number of households and seeing if people could figure it out/actually used it properly) seems like an easy next step for the paper that they missed.

[anguyen0204]

Reviewer: Andrew Nguyen Review Type: Skim

Problem Being Solved The paper observes the security aspect of devices and that what can be done to prevent unwanted connections and potential attacks. It talks about examples of attacks and how to prevent it including ways of implementing functions.

Main Contributions Bark is discussed, which is a system that monitors and decides who the device communications and interactions. In addition, Bark incorporates the concept of default-off policy. Therefore, devices will communicate unless it is specifically authorized.

Questions:

1. In the over-permissioned cloud portion of the paper how can the user do something to differentiate and depend adjust accordingly since no one knows when they are attacked exactly.

[huachuan]

Reviewer: Huachuan Wang Review Type: Critical

Problem Being Solved

In this paper, the author states that IoT devices create lots of security vulnerabilities in computing networks. The author suggests that we should default-off IoT device communications and explicitly enabled desired network communications. IoT applications and devices should serve narrowly defined purposes and do not require access to all services in the network. This paper introduced Bark for specifying and enforcing minimal access permissions in IoT networks. The bark is a policy language and runtime phrases access control policies in terms of who, what, where, when, and how questions and transforms them into transparently enforceable rules for IoT application protocols. Bark can express detailed rules in a way that is presentable and explainable to users. This paper also implements Bark for Wi-Fi/IP and BLE networks and evaluate its efficacy on several example applications and attacks.

Main Contributions

This paper introduces a default-off communication model for the IoT to defend devices from network attacks. It justifies default-off by analyzing recent attacks and vulnerabilities and by measuring the traffic patterns of a number of popular consumer IoT devices. This paper also proposed the Bark specification language for whitelisting access to IoT applications. A practical application of two-factor authentication style schemes to express network access control policies that require a user-in-the-loop or non-network context. For example, “Let my friend’s phone unlock my front door if I approve it via SMS.”

Questions

1. As Bark can only whitelist access, why it could not inherently prevent overly generic rules from being written? I cannot understand why the overly generic rules could be easily identified and removed?

2. In the evaluation section, the author states that the static elements of rules can be accessed use SQL, why that the wild cards are not static elements and cannot be put into the SQL to reduce latency?

Critiques

1. This paper presents the default-off model which is very appealing. However, whitelist access control might have more ways to solve and improve. First, the user should not be granted to use overly generic rules. Second, the rules might have ambiguities, this paper only states the ambiguities brought by *. Third, incomplete rules and requests are not taken into consideration.

2. Network security of IoT devices might be able to be improved, however, add more vulnerabilities by using a local database, the database could be modified and deleted by adversaries.

[tuhinadasgupta]

Reviewer: Tuhina Review Type: Critical

Problem: This paper addresses the security vulnerabilities that are present in IoT computing networks. They suggest that IoT devices should be restricted to the minimum access needed for their required task. Their solution, named Bark, can specify and enforce these permissions.

Contributions: Their solution, Bark can explain detailed rules in a way that is simple for users to understand. This paper also implements Bark for Wi-Fi/IP and BLE networks and evaluate its efficacy on several example applications and attacks. Bark additionally gives users the ability to exercise access control and enforce whitelists for their IoT applications and devices.

Questions:

1. Bark gives users a lot of control over their settings, which is great but also introduces risk as shown by the example of being offsite and still being able to change settings. How will this be addressed?
2. What if the WiFi is unstable?

Critiques

1. As with question 1, the determination of if a user is at home needs to be extremely accurate but I'm uncertain that it is.
2. This is supposed to increase security so I'm curious if IoT devices that need to be secure (ie. smart home) will adopt this technology as it could produce more security risk in a system