Background. With a projected rise in the procurement of home automation systems, we experimentally investigate security risks that homeowners might be exposed to by compact fluorescent lamps (CFL), where the lamps themselves do not have network capabilities but are controlled by compromised Internet-enabled home automation systems. Aim. This work seeks to investigate the feasibility of causing physical harm—such as through the explosion of CFLs—to home occupants through an exploited home automation system. Method. We set up a model of a compromised automated home; placing emphasis on a connected Z-Wave enabled light dimmer. Four distinct electrical signals were then applied to two different brands of CFLs connected to a ZWave enabled light dimmer until they popped or gave way. Results. Three of ten CFLs on which we conducted our experiments popped, although not to the degree of explosions we expected. The seven remaining CFLs gave way with varying times to failure indicating process and design variations. We did find that it was possible to produce fluctuations at an appropriate frequency to induce seizures. We were also able to remotely compromise a home automation controller over the Internet. Due to timing constraints, however, we were only able to compromise the light bulbs via an adversary-controlled device using open-zwave libraries, and not via the compromised controller. Conclusions. Our results demonstrated that it will be hard for an attacker to use the described methods to harm homeowners, although we do demonstrate the possibility of attacks, particularly if the homeowner suffers from epilepsy. However, and more importantly, our work demonstrates that non-networked devices—such as light bulbs—might be connected to networked devices and hence can be attacked by remote adversaries. 1 We define popped as the visual or auditory observance of a spark in the CFL. 2 The term “give way” refers to the normal failure of a CFL without a spark. General Terms Experimentation, Measurement.
• Background. This paper explores associations of computer compromise events in relationship to web browsing activity over a population of computers. • Aim. Our hypothesis was that computers are more likely to be compromised in comparison to other computers when the computer regularly browses to web sites prior to other computers visiting the same site (early adopters) or browses to unique web sites that no other computer visited (unique adopters) in a given time period. • Method. Web proxy data and associated computerspecific compromise events covering 24,000+ computers in a contiguous 6 month time period were used to group computers in various adopter categories and compare potential compromise events between the groups. • Results. We found distinction in web surfing behavior, in some cases differentiating the chance of compromise from 2.5-fold to over 418-fold between certain adopter categories. However, the study also showed no additional value in predicting compromise using these more complex adopter categories when compared to using simple unique web activity counts. As additional contributions, we have characterized several large, real-work cyber defense relevant data sets and introduced a method for simplifying web URLS (client web requests) that reduces unwanted uniqueness from dynamic content while preserving key characteristics. • Conclusions. We found that a count of unique web visits over time has the same level of predictive power for potential compromise as does the more complicated web adopter model. Both models have better than chance levels of prediction but also reinforce the idea that many factors beyond elements of web browsing activity are associated with computer compromise events. Nonetheless, our adopter model may still have value in objective computer risk determination based on web browsing behavior.
• Background. The security and privacy communities have become increasingly interested in results from behavioral economics and psychology to help frame decisions so that users can make better privacy and security choices. One such result in the literature suggests that cognitive disfluency (presenting questions in a hard-to-read font) reduces selfdisclosure. • Aim. To examine the replicability and reliability of the effect of disfluency on self-disclosure, in order to test whether such approaches might be used to promote safer security and privacy behaviors. • Method. We conducted a series of survey studies on human subjects with two conditions disfluent and fluent font. The surveys were completed online (390 participants throughout the United States), on tablets (93 students) and with pen and paper (three studies with 89, 61, and 59 students). The pen and paper studies replicated the original study exactly. We ran an independent samples t-test to check for significant differences between the averages of desirable responses across the two conditions. • Results. In all but one case, participants did not show lower self-disclosure rates under disfluent conditions using an independent samples t-test. We re-analyzed the original data and our data using the same statistical test (paired t-test) as used in the original paper, and only the data from the original published studies supported the hypothesis. • Conclusions.We argue that the effect of disfluency on disclosure originally reported in the literature might result from the choice of statistical analysis, and that disfluency does not reliably or consistently affect self-disclosure. Thus, disfluency may not be relied on for interface designers trying to improve security or privacy decision making.
Background. Security bugs are critical programming errors that can lead to serious vulnerabilities in software. Such bugs may allow an attacker to take over an application, steal data or prevent the application from working at all. Aim. We used the projects stored in the Maven repository to study the characteristics of security bugs individually and in relation to other software bugs. Specifically, we studied the evolution of security bugs through time. In addition, we examined their persistence and their relationship with a) the size of the corresponding version, and b) other bug categories. Method. We analyzed every project version of the Maven repository by using FindBugs, a popular static analysis tool. To see how security bugs evolve over time we took advantage of the repository’s project history and dependency data. Results. Our results indicate that there is no simple rule governing the number of security bugs as a project evolves. In particular, we cannot say that across projects security-related defect counts increase or decrease significantly over time. Furthermore, security bugs are not eliminated in a way that is particularly different from the other bugs. In addition, the relation of security bugs with a project’s size appears to be different from the relation of the bugs coming from other categories. Finally, even if bugs seem to have similar behaviour, severe security bugs seem to be unassociated with other bug categories. Conclusions. Our findings indicate that further research should be done to analyze the evolution of security bugs. Given the fact that our experiment included only Java projects, similar research could be done for another ecosystem. Finally, the fact that projects have their own idiosyncrasies concerning security bugs, could help us find the common characteristics of the projects where security bugs increase over time.
