SEAD '18- Proceedings of the 1st International Workshop on Security Awareness from Design to Deployment

Continuous deployment is a software engineering process where incremental software changes are automatically tested and frequently deployed to production environments. With continuous deployment, the elapsed time for a change made by a developer to reach a customer can now be measured in days or even hours. To understand the emerging practices surrounding continuous deployment, three annual one-day Continuous Deployment Summits have been held at Facebook, Netflix, and Google in 2015--2017, where 17 companies have described how they used continuous deployment. This short paper will describe the practices and environment used by these companies as they strive to develop secure and privacy-preserving products while making ultra-fast changes.

The security of a company's software products is of paramount importance, of course, and arguably even more important than software reliability and the other key quality attributes. But companies are currently faced with a troublesome dilemma: Supplying customers with more features at greater speeds than in the past has become the norm; high feature velocity, fairly static engineering headcounts, and shorter release cycles are conspiring to threaten both software reliability and security. The work described in this paper is an attempt to baseline and (internally) benchmark the state of our company's software security, and also includes some data regarding the state of software reliability across the company's products. Of particular interest in this study is learning more about the extent of software vulnerabilities emanating from the open source software that we import and use in our commercial products. Prior evidence had been building that suggested that such `third-party software' (TPS) is inherently more vulnerable to security (and reliability) problems. We have examined the software vulnerability occurrences across all the company's software, in the aggregate, and have found that the TPS used in our products, primarily open source software, initially contains more vulnerabilities than internally-produced software. Security and reliability problems, both in terms of bug counts and percentages of total code volume, correlate quite well, and examples of this are also shown, but we cannot rely on this concurrence in our study: Software security on its own has been examined in detail, and while some findings are documented here, many questions remain.

Implementing security by design in practice often involves the application of threat modeling to elicit security threats and to aid designers in focusing efforts on the most stringent problems first.

Existing threat modeling methodologies are capable of generating lots of threats, yet they lack even basic support to triage these threats, except for relying on the expertise and manual assessment by the threat modeler.

Since the essence of creating a secure design is to minimize associated risk (and countermeasure costs), risk analysis approaches offer a very compelling solution to this problem. By combining risk analysis and threat modeling, elicited threats in a design can be enriched with risk analysis information in order to provide support in triaging and prioritizing threats and focusing security efforts on the high-risk threats. It requires the following inputs: the asset values, the strengths of countermeasures, and an attacker model.

In his paper, we provide an integrated threat elicitation and risk analysis approach, implemented in a threat modeling tool prototype, and evaluate it using a real-world application, namely the SecureDrop whistleblower submission system. We show that the security measures implemented in SecureDrop indeed correspond to the high-risk threats identified by our approach. Therefore, the risk-based security analysis provides useful guidance on focusing security efforts on the most important problems first.

Android applications (apps) are not immune to the problems which also plague conventional software including security vulnerabilities, quality defects, permission misuse, and numerous other issues. Many developers even intentionally create vulnerable or malicious apps (malware) for often highly lucrative purposes. We need to better understand current trends in app quality and security to create higher quality software, and more effectively battle malware. To gather this critical information, we collected and reverse engineered 70,785 Android apps from the Google Play store, along with 1,420 malicious apps from other sources. Each app was analyzed using several static analysis tools to record a variety of information about each of them including requested permissions, size (LOC), possible defects and permission misuse. Our findings conclude that: 1) app categories substantially differ in terms of permissions misuse; 2) at an aggregate level, there is no significant correlation between an app's quality and security; 3) that malware typically requests more permissions and suffers from several quality-related metrics in comparison to benign apps; 4) that malware and benign apps are growing annually both in terms of LOC and requested permissions. We also present an easy to use, robust dataset for the community to replicate or extend this study.

Developers turn to Stack Overflow and other on-line sources to find solutions to security problems, but little is known about how they engage with and guide one another in these environments or the perceptions of software security this may encourage. This study joins recent calls to understand more about how developers use Internet sources to solve security problems. Using qualitative methods, a set of questions within the security channel of Stack Overflow were selected and examined for themes. Preliminary findings reveal more about this community of practitioners: who are the askers and commenters, how security questions are asked and how developers frame technical information using social and experience-based perceptions of security.

An increasing number of security incidents in cyber-physical systems (CPSs) arise from the exploitation of cyber and physical components of such systems. Knowledge about how such incidents arose is rarely captured and used systematically to enhance security and support future incident investigations. In this paper, we propose an approach to represent and share incidents knowledge. Our approach captures incident patterns - common aspects of incidents occurring in different CPSs. Our approach then allows incident patterns to be instantiated for different systems to assess if and how such patterns can manifest again. To support our approach, we provide two meta-models that represent, respectively, incident patterns and the cyber-physical systems themselves. The incident meta-model captures the characteristics of incidents, such as assets and activities. The system meta-model captures cyber and physical components and their interactions, which may be exploited during an incident. We demonstrate the feasibility of our approach in the application domain of smart buildings, by tailoring the system meta-model to represent components and interactions in this domain.

In this vision paper, we focus on a key aspect of the modern software developer's potential to write secure software: their (lack of) success in securely using cryptography APIs. In particular, we note that most ongoing research tends to focus on identifying concrete problems software developers experience, and providing workable solutions, but that such solutions still require developers to identify the appropriate API calls to make and, worse, to be familiar with and configure sometimes obscure parameters of such calls. In contrast, we envision identifying and employing targeted visual metaphors to allow developers to simply select the most appropriate cryptographic functionality they need.

Security patterns are intended to package reusable security solutions and have received considerable research attention in the two decades since their introduction. Practitioners seem less intent to use these security patterns while designing software, though, despite the prevalence of reuse in secure software engineering. We believe this is primarily because current security patterns do not tackle the security problems practitioners actually face.

In this vision paper, we conceive a new way for expressing security patterns, built on a set of reusable and well-known security building blocks. We also advocate the inclusion of these building blocks as first-class citizens in a security-specific modelling language. This not only facilitates unambiguous communication of security solutions such as patterns, but also allows designers to construct a security view of their design which in turn opens new avenues for a broader security by design methodology.

DLR as research organization increasingly faces the task to share its self-developed software with partners or publish openly. Hence, it is very important to harden the softwares to avoid opening attack vectors. Especially since DLR software is typically not developed by software engineering or security experts. In this paper we describe the data-oriented approach of our new found secure software engineering group to improve the software development process towards more secure software. Therefore, we have a look at the automated security evaluation of software as well as the possibilities to capture information about the development process. Our aim is to use our information sources to improve software development processes to produce high quality secure software.

The reality of today's computing landscape already suffers from a shortage of cybersecurity professionals, and this gap only expected to grow. We need to generate interest in this STEM topic early in our student's careers and provide teachers the resources they need to succeed in addressing this gap. To address this shortfall we present Practical LAbs in Security for Mobile Applications (PLASMA), a public set of educational security labs to enable instruction in creation of secure Android apps. These labs include example vulnerable applications, information about each vulnerability, steps for how to repair the vulnerabilities, and information about how to confirm that the vulnerability has been properly repaired. Our goal is for instructors to use these activities in their mobile, security, and general computing courses ranging from secondary school to university settings. Another goal of this project is to foster interest in security and computing through demonstrating its importance. Initial feedback demonstrates the labs' positive effects in enhancing student interest in cybersecurity and acclaim from instructors. All project activities may be found on the project website: http://www.TeachingMobileSecurity.com