Malicious communications aimed at tricking employees are a serious threat for organizations, necessitating the creation of procedures and policies for quickly respond to ongoing attacks. While automated measures provide some protection, they cannot completely protect an organization. In this case study, we use interviews and observations to explore the processes staff at a large University use when handling reports of malicious communication, including how the help desk processes reports, whom they escalate them to, and how teams who manage protections such as the firewalls and mail relays use these reports to improve defenses. We found that the process and work patterns are a distributed cognitive process requiring multiple distinct teams with narrow system access and tactic knowledge. Sudden large campaigns were found to overwhelm the help desk with reports, greatly impacting staff's workflow and hindering the effective application of mitigations and the potential for reflection. We detail potential improvements to ticketing systems and reflect on ITIL, a common framework of best practice in IT management.

Applying regular patches is vital for the timely correction of security vulnerabilities, but installing patches also risks disrupting working systems by potentially introducing unknown errors. System administrators must manage the challenges of patching using a combination of reliance on best practice and available information to best match their organizations' needs. In this work, we study how patchrelated activities are supported by the mailing list of the website PatchManagement.org which is dedicated to the task. We qualitatively coded 356 list emails sent between March and July, 2018, to understand how members interact with the list community. Based on our results, we argue that the mailing list is an example of an Online Community of Practice, where practitioners engage in communal learning and support. We find that the community supports members in multiple phases of the patching process by providing workarounds before a patch is available, guidance prioritizing released patches, and helping with post-patch trouble. Additionally, the community provides help around tool selection and facilitating discussions.

The security attitudes and approaches of software developers have a large impact on the software they produce, yet we know very little about how and when these views are constructed. This paper investigates the security and privacy (S&P) perceptions, experiences, and practices of current Computer Science students at the graduate and undergraduate level using semi-structured interviews. We find that the attitudes of students already match many of those that have been observed in professional level developers. Students have a range of hacker and attack mindsets, lack of experience with security APIs, a mixed view of who is in charge of S&P in the software life cycle, and a tendency to trust other peoples' code as a convenient approach to rapidly build software. We discuss the impact of our results on both curriculum development and support for professional developers.

No abstract

Particle beam modeling in accelerators has been the focus of considerable effort since the 1950s. Many generations of tools have resulted from this process, each leveraging both prior experience and increases in computer power. However, continuing innovation in accelerator technology results in systems that are not well described by existing tools, so the software development process is on-going. We discuss a novel response to this situation, which was encountered when Jefferson Lab began operation of its energy-recovering linacs. These machines were not readily described with legacy software; therefore a model was built using Microsoft Excel. This interactive simulation can query data from the accelerator, use it to compute machine parameters, analyze difference orbit data, and evaluate beam properties. It can also derive new accelerator tunings and rapidly evaluate the impact of changes in machine configuration. As it is spreadsheet-based, it can be easily user-modified in response to changing requirements. Examples for the JLab IR Upgrade FEL are presented. DEVELOPMENT PARADIGMSHigh-level accelerator applications have been generated within many organizational models, most of which comprise a "client/vendor" relationship. In this paradigm, a "client" (the user) contracts with a "vendor" (a software source) to provide a tool meeting defined requirements. The client states the requirements; the vendor is free to construct the application in any manner consistent with the defined criteria. Typically, the product will be general, robust, and secure. The user is, however, largely insulated from the development process, and often has limited ability to modify the tool. The overhead of changing or evolving requirements is therefore often high.At the JLab FEL we have employed a different approach, wherein the emphasis is on development ease and speed, modifiability, and user accessibility.Applications developed under such a paradigm can be viewed as "just in time" products, created as "disposable", "near-run-time" codes intended for a specific purpose.As an alternative to the client/vendor paradigm, consider then a "development" paradigm, wherein the user is provided a development environment, not an application. At or near run time, she develops an application tailored for use in a single instance. In this scenario, emphasis is placed on use of existing tools, ease and speed of development and modification, and user accessibility, rather than robustness, generality, and completeness, while maintaining required accuracy. Given the assumed ease of development under such a paradigm, the traditional requirements are not necessary to meet -if the software has a deficiency, it is modified at run time rather than off line! In the context of accelerator operation and control, the "development paradigm" user is provided an environment and data access tools. With appropriate development methods, she captures needed data, construct tools for its analysis, and determines outcomes that are applied to the accelerator. Examples of s...