Biblio

An Assessment of Security Problems in Open Source Software: Improving software security through changes in software design and development processes appears to be a very hard problem. For example, well documented security issues such as Structured Query Language injection, after more than a decade, still tops most vulnerability lists. Security priority is often subdued due to constraints such as time-to-market and resources. Furthermore, security process outcomes are hard to quantify and even harder to predict or relate to process improvement activities. In part this is because of the nature of the security faults - they are in statistical terms "rare" and often very complex compared to "regular" non-security faults. In part it is the irregular and unpredictable nature of the security threats and attacks that puts the software under attack into states it was not designed for and subjects it to what would be considered "nonoperational" use. In many cases it is the human component of the system that fails - for example, due to phishing or due to incorrect use of a software product. On the other hand, we have decades of experience developing reliable software (admittedly subject to similar resource, cost and time constraints). The central question of interest in this thesis is to what extent can we leverage some of the software reliability engineering (SRE) models, processes, and metrics that work in the "classical" operational space to develop predictive software security engineering assessment and development elements. Specific objectives are a) to investigate use of (possibly modified) SRE practices to characterize security properties of software, and b) assess how software design and development processes could be enhanced to avoid, eliminate and tolerate security problems and attacks.We are particularly interested in open source software security, the conditions under which SRE practices may be useful, and the information that this can provide about the security quality of a software product. We examined public information about security problem reports for open source Fedora and RHEL series of software releases, Chromium project and Android project. The data that we analyzed was primarily about security problems reported from post-release in-the-field use of the products. What can we learn about the non-operational processes (and possible threats) related to security problems? One aspect is classification of security problems based on the traits that contribute to the injection of problems into code, whether due to poor practices or limited knowledge (epistemic errors), or due to random accidental events (aleatoric errors). Knowing the distribution can help understand attack space and help improve development processes and testing of the next version. For example, in the case of Fedora, the distribution of security problems found post-release was consistent across two different releases of the software. The security problem discovery rate appears to be roughly constant but much lower (ten to a hundred times lower) than the initial non-security problem discovery rate. Similarly, in the case of RHEL, the distribution of security problems found post-release was consistent and the number of security problems kept decreasing across six different releases of the software. The security problem discovery rate appears to be roughly constant but again much lower than the initial non-security problem discovery rate. In the case of Chromium, the number of discovered security problems is orders of magnitude higher than for other products, except that does not appear to translate into a higher incidence of field breaches. One reason could be Chromium "bounty" for problem discovery. We find that some classical reliability models can be used as one of tools to estimate the residual number of security problems in both the current release and in the future releases of the software, and through that provide a measure of the security characteristics of the software. For example, to assess whether, under given usage conditions, security problem discovery rate is increasing or decreasing - and what that may mean. Based on our findings, we discuss an agile software testing process that combines operational and non-operational (or attack related) testing with the intent of finding and eliminating more security problems earlier in the software development process. The knowledge of vulnerable components from architectural view and the frequency of vulnerabilities in each of the components helps in prioritizing security test resources.

Software as a Service (SaaS) is the most prevalent service delivery mode for cloud systems. This paper surveys common security vulnerabilities and corresponding countermeasures for SaaS. It is primarily focused on the work published in the last five years. We observe current SaaS security trends and a lack of sufficiently broad and robust countermeasures in some of the SaaS security area such as Identity and Access management due to the growth of SaaS applications.

Hadoop is a map-reduce implementation that rapidly processes data in parallel. Cloud provides reliability, flexibility, scalability, elasticity and cost saving to customers. Moving Hadoop into Cloud can be beneficial to Hadoop users. However, Hadoop has two vulnerabilities that can dramatically impact its security in a Cloud. The vulnerabilities are its overloaded authentication key, and the lack of fine-grained access control at the data access level. We propose and develop a security enhancement for Cloud-based Hadoop.

Hadoop has become increasingly popular as it rapidly processes data in parallel. Cloud computing gives reli- ability, flexibility, scalability, elasticity and cost saving to cloud users. Deploying Hadoop in cloud can benefit Hadoop users. Our evaluation exhibits that various internal cloud attacks can bypass current Hadoop security mechanisms, and compromised Hadoop components can be used to threaten overall Hadoop. It is urgent to improve compromise resilience, Hadoop can maintain a relative high security level when parts of Hadoop are compromised. Hadoop has two vulnerabilities that can dramatically impact its resilience. The vulnerabilities are the overloaded authentication key, and the lack of fine-grained access control at the data access level. We developed a security enhancement for a public cloud-based Hadoop, named SEHadoop, to improve the compromise resilience through enhancing isolation among Hadoop components and enforcing least access privilege for Hadoop processes. We have implemented the SEHadoop model, and demonstrated that SEHadoop fixes the above vulnerabilities with minimal or no run-time overhead, and effectively resists related attacks.

Phishing is an act of technology-based deception that targets individuals to obtain information. To minimize the number of phishing attacks, factors that influence the ability to identify phishing attempts must be examined. The present study aimed to determine how individual differences relate to performance on a phishing task. Undergraduate students completed a questionnaire designed to assess impulsivity, trust, personality characteristics, and Internet/security habits. Participants performed an email task where they had to discriminate between legitimate emails and phishing attempts. Researchers assessed performance in terms of correctly identifying all email types (overall accuracy) as well as accuracy in identifying phishing emails (phishing accuracy). Results indicated that overall and phishing accuracy each possessed unique trust, personality, and impulsivity predictors, but shared one significant behavioral predictor. These results present distinct predictors of phishing susceptibility that should be incorporated in the development of anti-phishing technology and training.

In highly configurable systems the configuration space is too big for (re-)certifying every configuration in isolation. In this project, we combine software analysis with network analysis to detect which configuration options interact and which have local effects. Instead of analyzing a system as Linux and SELinux for every combination of configuration settings one by one (>102000 even considering compile-time configurations only), we analyze the effect of each configuration option once for the entire configuration space. The analysis will guide us to designs separating interacting configuration options in a core system and isolating orthogonal and less trusted configuration options from this core.

Complex software systems are becoming increasingly prevalent in aerospace applications: in particular, to
accomplish critical tasks. Ensuring the safety of these systems is crucial, as they can have subtly different behaviors
under slight variations in operating conditions. This paper advocates the use of formal verification techniques and in
particular theorem proving for hybrid software-intensive systems as a well-founded complementary approach to the
classical aerospace verification and validation techniques, such as testing or simulation. As an illustration of these
techniques, a novel lateral midair collision-avoidance maneuver is studied in an ideal setting, without accounting for
the uncertainties of the physical reality. The challenges that naturally arise when applying such technology to
industrial-scale applications is then detailed, and proposals are given on how to address these issues.

We present an architecture for the Security Behavior Observatory
(SBO), a client-server infrastructure designed to
collect a wide array of data on user and computer behavior
from hundreds of participants over several years. The SBO
infrastructure had to be carefully designed to fulfill several
requirements. First, the SBO must scale with the desired
length, breadth, and depth of data collection. Second, we
must take extraordinary care to ensure the security of the
collected data, which will inevitably include intimate participant
behavioral data. Third, the SBO must serve our
research interests, which will inevitably change as collected
data is analyzed and interpreted. This short paper summarizes
some of our design and implementation benefits and
discusses a few hurdles and trade-offs to consider when designing
such a data collection system.

Much of the data researchers usually collect about users’ privacy and security behavior comes from short-term studies and focuses on specific, narrow activities. We present a design architecture for the Security Behavior Observatory (SBO), a client-server infrastructure designed to collect a wide array of data on user and computer behavior from a panel of hundreds of participants over several years. The SBO infrastructure had to be carefully designed to fulfill several requirements. First, the SBO must scale with the desired length, breadth, and depth of data collection. Second, we must take extraordinary care to ensure the security and privacy of the collected data, which will inevitably include intimate details about our participants' behavior. Third, the SBO must serve our research interests, which will inevitably change over the course of the study, as collected data is analyzed, interpreted, and suggest further lines of inquiry. We describe in detail the SBO infrastructure, its secure data collection methods, the benefits of our design and implementation, as well as the hurdles and tradeoffs to consider when designing such a data collection system. - See more at: https://www.cylab.cmu.edu/research/techreports/2014/tr_cylab14009.html#sthash.vsO39UdR.dpuf

Online cyber threat descriptions are rich, but little research has attempted to systematically analyze these descriptions. In this paper, we process and analyze two of Symantec’s online threat description corpora. The Anti-Virus (AV) corpus contains descriptions of more than 12,400 threats detected by Symantec’s AV, and the Intrusion Prevention System (IPS) corpus contains descriptions of more than 2,700 attacks detected by Symantec’s IPS. In our analysis, we quantify the over time evolution of threat severity and type in the corpora. We also assess the amount of time Symantec takes to release signatures for newly discovered threats. Our analysis indicates that a very small minority of threats in the AV corpus are high-severity, whereas the majority of attacks in the IPS corpus are high-severity. Moreover, we find that the prevalence of different threat types such as worms and viruses in the corpora varies considerably over time. Finally, we find that Symantec prioritizes releasing signatures for fast propagating threats.

Very often in the software development life cycle, security is applied too late or important security aspects are overlooked. Although the use of security patterns is gaining popularity, the current state of security requirements patterns is such that there is not much in terms of a defining structure. To address this issue, we are working towards defining the important characteristics as well as the boundaries for security requirements patterns in order to make them more effective. By examining an existing general pattern format that describes how security patterns should be structured and comparing it to existing security requirements patterns, we are deriving characterizations and boundaries for security requirements patterns. From these attributes, we propose a defining format. We hope that these can reduce user effort in elicitation and specification of security requirements patterns.

Despite the abundance of information security guidelines, system developers have difficulties implementing technical solutions that are reasonably secure. Security patterns are one possible solution to help developers reuse security knowledge. The challenge is that it takes experts to develop security patterns. To address this challenge, we need a framework to identify and assess patterns and pattern application practices that are accessible to non-experts. In this paper, we narrowly define what we mean by patterns by focusing on requirements patterns and the considerations that may inform how we identify and validate patterns for knowledge reuse. We motivate this discussion using examples from the requirements pattern literature and theory in cognitive psychology.

Software patterns are created with the goal of capturing expert
knowledge so it can be efficiently and effectively shared with the
software development community. However, patterns in practice
may or may not achieve these goals. Empirical studies of the use
of software patterns can help in providing deeper insight into
whether these goals have been met. The objective of this paper is
to aid researchers in designing empirical studies of software
patterns by summarizing the study designs of software patterns
available in the literature. The important components of these
study designs include the evaluation criteria and how the patterns
are presented to study participants. We select and analyze 19
distinct empirical studies and identify 17 independent variables in
three different categories (participants demographics; pattern
presentation; problem presentation). We also extract 10 evaluation
criteria with 23 associated observable measures. Additionally, by
synthesizing the reported observations, we identify challenges
faced during study execution. Provision of multiple domainspecific
examples of pattern application and tool support to assist
in pattern selection are helpful for the study participants in
understanding and completing the study task. Capturing data
regarding the cognitive processes of participants can provide
insights into the findings of the study.

As information security became an increasing
concern for software developers and users, requirements
engineering (RE) researchers brought new insight to security
requirements. Security requirements aim to address security at
the early stages of system design while accommodating the
complex needs of different stakeholders. Meanwhile, other
research communities, such as usable privacy and security,
have also examined these requirements with specialized goal to
make security more usable for stakeholders from product
owners, to system users and administrators. In this paper we
report results from conducting a literature survey to compare
security requirements research from RE Conferences with the
Symposium on Usable Privacy and Security (SOUPS). We
report similarities between the two research areas, such as
common goals, technical definitions, research problems, and
directions. Further, we clarify the differences between these
two communities to understand how they can leverage each
other’s insights. From our analysis, we recommend new
directions in security requirements research mainly to expand
the meaning of security requirements in RE to reflect the
technological advancements that the broader field of security is
experiencing. These recommendations to encourage crosscollaboration
with other communities are not limited to the
security requirements area; in fact, we believe they can be
generalized to other areas of RE.

Information system developers and administrators often overlook critical security requirements and best practices. This may be due to lack of tools and techniques that allow practitioners to tailor security knowledge to their particular context. In order to explore the impact of new security methods, we must improve our ability to study the impact of security tools and methods on software and system development. In this paper, we present early findings of an experiment to assess the extent to which the number and type of examples used in security training stimuli can impact security problem solving. To motivate this research, we formulate hypotheses from analogical transfer theory in psychology. The independent variables include number of problem surfaces and schemas, and the dependent variable is the answer accuracy. Our study results do not show a statistically significant difference in performance when the number and types of examples are varied. We discuss the limitations, threats to validity and opportunities for future studies in this area.

Project documentation often contains security-relevant statements that are indicative of the security requirements of a system. However these statements may not be explicitly specified or straightforward to locate. At best, requirements analysts manually extract applicable security requirements from project documents. However, security requirements that are not explicitly stated may not be considered during implementation. The goal of this research is to aid requirements analysts in generating security requirements through identifying securityrelevant statements in project documentation and providing context-specific templates to generate security requirements. First, we identify the most prevalent security objectives from software security literature. To identify security-relevant statements in project documentation, we propose a tool-based process to classify statements as related to zero or more security objectives. We then develop a set of context-specific templates to help translate the security objectives of each statement into explicit sets of security functional requirements. We evaluate our process on six documents from the electronic healthcare software industry, identifying 46% of statements as implicitly or explicitly related to security. Our classification approach identified security objectives with a precision of .82 and recall of .79. From our total set of classified statements, we extracted 16 context-specific templates that identify 41 reusable security requirements.

Security requirements patterns represent reusable security practices that software engineers can apply to improve security in their system. Reusing best practices that others have employed could have a number of benefits, such as decreasing the time spent in the requirements elicitation process or improving the quality of the product by reducing product failure risk. Pattern selection can be difficult due to the diversity of applicable patterns from which an analyst has to choose. The challenge is that identifying the most appropriate pattern for a situation can be cumbersome and time-consuming. We propose a new method that combines an inquiry-cycle based approach with the feature diagram notation to review only relevant patterns and quickly select the most appropriate patterns for the situation. Similar to patterns themselves, our approach captures expert knowledge to relate patterns based on decisions made by the pattern user. The resulting pattern hierarchies allow users to be guided through these decisions by questions, which introduce related patterns in order to help the pattern user select the most appropriate patterns for their situation, thus resulting in better requirement generation. We evaluate our approach using access control patterns in a pattern user study.

Research shows that commonly accepted security requirements are not generally applied in practice. Instead of relying on requirements checklists, security experts rely on their expertise and background knowledge to identify security vulnerabilities. To understand the gap between available checklists and practice, we conducted a series of interviews to encode the decision-making process of security experts and novices during security requirements analysis. Participants were asked to analyze two types of artifacts: source code, and network diagrams for vulnerabilities and to apply a requirements checklist to mitigate some of those vulnerabilities. We framed our study using Situation Awareness-a cognitive theory from psychology-to elicit responses that we later analyzed using coding theory and grounded analysis. We report our preliminary results of analyzing two interviews that reveal possible decision-making patterns that could characterize how analysts perceive, comprehend and project future threats which leads them to decide upon requirements and their specifications, in addition, to how experts use assumptions to overcome ambiguity in specifications. Our goal is to build a model that researchers can use to evaluate their security requirements methods against how experts transition through different situation awareness levels in their decision-making process.