CSET '17 Workshop Program

Embedded phishing exercises, which send test phishing emails, are utilized by organizations to reduce the susceptibility of its employees to this type of attack. Research studies seeking to evaluate the effectiveness of these exercises have generally been limited by small sample sizes. These studies have not been able to measure possible factors that might bias results. As a result, companies have had to create their own design and evaluation methods, with no framework to guide their efforts. Lacking such guidelines, it can often be difficult to determine whether these types of exercises are truly effective, and if reported results are statistically reliable.

In this paper, we conduct a systematic analysis of data from a large real world embedded phishing exercise that involved 19,180 participants from a single organization, and utilized 115,080 test phishing emails. The first part of our study focuses on developing methodologies to correct some sources of bias, enabling sounder evaluations of the efficacy of embedded phishing exercises and training. We then use these methods to perform an analysis of the effectiveness of this embedded phishing exercise, and through our analysis, identify how the design of these exercises might be improved.

This paper describes a set of experiments we conducted to answer the question: just how prevalent is Internet interception? That is, if we sent our most sensitive information (bank information, passwords, etc.) in the clear, should we expect to regret it?

For a little over a year, we sent different types of Internet traffic over unencrypted channels between multiple clients and servers located at geographically diverse locations around the globe. Our messages contained seemingly sensitive and valuable information, including login credentials for banking sites, password reset links, etc. In total, we found no instances in which our information was acted upon by an eavesdropper.

This paper details the numerous challenges— technical, legal, and ethical—of setting up and maintaining a year-long, large-scale honeytrap. We discuss some fundamental limitations of such an experiment, and argue why our results should not be misinterpreted to suggest that message encryption is gratuitous.

Recent years have seen a number of cyber attacks targeting Industrial Control Systems (ICSs). Reports detailing the findings from such attacks vary in detail. Hands-on experimental research is, therefore, required to better understand and explore security challenges in ICSs. However, real-world production systems are often off-limits due to the potential impact such research could have on operational processes and, in turn, safety. On the other hand, software-based simulations cannot always reflect all the potential device/system states due to oversimplified assumptions when modelling the hardware in question. As a result, laboratory-based ICS testbeds have become a key tool for research on ICS security. Development of such a testbed is a costly, labour- and time-intensive activity that must balance a range of design considerations, e.g., diversity of hardware and software platforms against scalability and complexity. Yet there is little coverage in existing literature on such design considerations, their implications and how to avoid typical pitfalls. Each group of researchers embarks on this journey from scratch, learning through a painful process of trial and error. In this paper we address this gap by reflecting on over 3 years of experience of building an extensive ICS testbed with a range of devices (e.g., PLCs, HMIs, RTUs) and software. We discuss the architecture of our testbed and reflect on our experience of addressing issues of diversity, scalability and complexity and design choices to manage trade-offs amongst these properties.

Security and privacy researchers are increasingly conducting controlled experiments focusing on IT professionals, such as software developers and system administrators. These professionals are typically more difficult to recruit than general end-users. In order to allow for distributed recruitment of IT professionals for security user studies, we designed Developer Observatory, a browser-based virtual laboratory platform that enables controlled programming experiments while retaining most of the observational power of lab studies. The Developer Observatory can be used to conduct large-scale, reliable online programming studies with reasonable external validity. We report on our experiences and lessons learned from two controlled programming experiments (n>200) conducted using Developer Observatory.

Malware samples are created at a pace that makes it difficult for analysis to keep up. When analyzing an unknown malware sample, it is important to assess its capabilities to determine how much damage it can make to its victims, and perform prioritization decisions on which threats should be dealt with first. In a corporate environment, for example, a malware infection that is able to steal financial information is much more critical than one that is sending email spam, and should be dealt with the highest priority. In this paper we present a statistical approach able to determine causality relations between a specific trigger action (e.g., a user visiting a certain website in the browser) and a malware sample. We show that we can learn the typology of a malware sample by presenting it with a number of trigger actions commonly performed by users, and studying to which events the malware reacts. We show that our approach is able to correctly infer causality relations between information stealing malware and login events on websites, as well as between adware and websites containing advertisements.

Memory management in a binary can be handled by a standard allocator (e.g. the libc allocator) or by a custom one. For many security and safety analysis focused on memory, the knowledge of the allocator is a requirement. In this paper, we propose an approach to retrieve allocators in binaries, based on heuristics and one single execution, with a scalable instrumentation. In addition, we propose a metric to evaluate the consistency of the detected allocator, in order to confirm or invalidate the result. Finally, we propose an open-source implementation and repeatable experiments. Preliminary results show that our approach allows to successfully retrieve the standard libc allocator in coreutils programs plus in mupdf, pdflatex and readelf; and the custom embedded allocator on jasper. They also confirm the relevance of our metric for consistency on these examples.