Biblio

In our previous work we showed that for Fedora, under normal operational conditions, security problem discovery appears to be a random process. While in the case of Fedora, and a number of other open source products, classical reliability models can be adapted to estimate the number of residual security problems under “normal” operational usage (not attacks), the predictive ability of the model is lower for security faults due to the rarity of security events and because there appears to be no real security reliability growth. The ratio of security to non-security faults is an indicator that the process needs improving, but it also may be leveraged to assess vulnerability profile of a release and possibly guide testing of its next version. We manually analyzed randomly sampled problems for four different versions of Fedora and classified them into security vulnerability categories. We also analyzed the distribution of these problems over the software’s lifespan and we found that they exhibit a symmetry which can perhaps be used in estimating the number of residual security problems in the software. Based on our work, we believe that an approach to vulnerability elimination based on a combination of “classical” and some non-operational “bounded” high-assurance testing along the lines discussed in may yield good vulnerability elimination results, as well as a way of estimating vulnerability level of a release. Classical SRE methods, metrics and models can be used to track both non-security and security problem detection under normal operational profile. We can then model the reliability growth, if any, and estimate the number of residual faults by estimating the lower and upper bounds on the total number of faults of a certain type. In production, there may be a simpler alternative. Just count the vulnerabilities and project over the next period assuming constant vulnerability discovery rate. In testing phase, to accelerate the process, one might leverage collected vulnerability information to generate non-operational test-cases aimed at vulnerability categories. The observed distributions of security problems reported under normal “operational” usage appear to support the above approach – i.e., what is learned say in the first x weeks can them be leveraged in selecting test cases in the next stage. Similarly, what is learned about a product Y weeks after its release may be very indicative of its vulnerability profile for the rest of its life given the assumption of constant vulnerability discovery rate.

We have developed a model for securing data-flow based application chains. We have imple- mented the model in the form of an add-on package for the scientific workflow system called Kepler. Our Security Analysis Package (SAP) leverages Kepler's Provenance Recorder (PR). SAP secures data flows from external input-based attacks, from access to unauthorized exter- nal sites, and from data integrity issues. It is not a surprise that cost of real-time security is a certain amount of run-time overhead. About half of the overhead appears to come from the use of the Kepler PR and the other half from security function added by SAP.

Automated cyber attacks tend to be schedule and resource limited. The primary progress metric is often “coverage” of pre-determined “known” vulnerabilities that may not have been patched, along with possible zero-day exploits (if such exist). We present and discuss a hypergeometric process model that describes such attack patterns. We used web request signatures from the logs of a production web server to assess the applicability of the model.

To help users create stronger text-based passwords, many web sites have deployed password meters that provide visual feedback on password strength. Although these meters are in wide use, their effects on the security and usability of passwords have not been well studied.

We present a 2,931-subject study of password creation in the presence of 14 password meters. We found that meters with a variety of visual appearances led users to create longer passwords. However, significant increases in resistance to a password-cracking algorithm were only achieved using meters that scored passwords stringently. These stringent meters also led participants to include more digits, symbols, and uppercase letters.

Password meters also affected the act of password creation. Participants who saw stringent meters spent longer creating their password and were more likely to change their password while entering it, yet they were also more likely to find the password meter annoying. However, the most stringent meter and those without visual bars caused participants to place less importance on satisfying the meter. Participants who saw more lenient meters tried to fill the meter and were averse to choosing passwords a meter deemed "bad" or "poor." Our findings can serve as guidelines for administrators seeking to nudge users towards stronger passwords.

During impact analysis on object-oriented code, statically extracting dependencies is often complicated by subclassing, programming to interfaces, aliasing, and collections, among others. When a tool recommends a large number of types or does not rank its recommendations, it may lead developers to explore more irrelevant code. We propose to mine and rank dependencies based on a global, hierarchical points-to graph that is extracted using abstract interpretation. A previous whole-program static analysis interprets a program enriched with annotations that express hierarchy, and over-approximates all the objects that may be created at runtime and how they may communicate. In this paper, an analysis mines the hierarchy and the edges in the graph to extract and rank dependencies such as the most important classes related to a class, or the most important classes behind an interface. An evaluation using two case studies on two systems totaling 10,000 lines of code and five completed code modification tasks shows that following dependencies based on abstract interpretation achieves higher effectiveness compared to following dependencies extracted from the abstract syntax tree. As a result, developers explore less irrelevant code.

In many scientific fields, simulations and analyses require compositions of computational entities such as web-services, programs, and applications. In such fields, users may want various trade-offs between different qualities. Examples include: (i) performing a quick approximation vs. an accurate, but slower, experiment, (ii) using local slower execution environments vs. remote, but advanced, computing facilities, (iii) using quicker approximation algorithms vs. computationally expensive algorithms with smaller data. However, such trade-offs are difficult to make as many such decisions today are either (a) wired into a fixed configuration and cannot be changed, or (b) require detailed systems knowledge and experimentation to determine what configuration to use. In this paper we propose an approach that uses architectural models coupled with automated design space generation for making fidelity and timeliness trade-offs. We illustrate this approach through an example in the intelligence analysis domain.

We have been studying extension of the classical Software Reliability Engineering (SRE) methodology into the security space. We combine “classical” reliability modeling, when applied to reported vulnerabilities found under “normal” operational profile conditions, with safety oriented fault management processes. We illustrate with open source Fedora software.

Our initial results appear to indicate that generation of a repeatable automated test-strategy that would explicitly cover the “top 25” security problems may help considerably – eliminating perhaps as much as 50% of the field observable problems. However, genuine aleatoric and more process oriented incomplete analysis and design flaws remain. While we have made some progress in identifying focus areas, a number of questions remain, and we continue working on them.

This paper presents an approach for securing software application chains in cloud environments. We use the concept of workflow management systems to explain the model. Our prototype is based on the Kepler scientific workflow system enhanced with security analytics package.

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.

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.

Can software reliability models be used to assess software security? One of the issues is that security problems are relatively rare under “normal” operational profiles, while “classical” reliability models may not be suitable for use in attack conditions. We investigated a range of Fedora open source software security problems to see if some of the basic assumptions behind software reliability growth models hold for discovery of security problems in non-attack situations. We find that in some cases, under “normal” operational use, security problem detection process may be described as a Poisson process. In those cases, we can use appropriate classical software reliability growth models to assess “security reliability” of that software in non-attack situations.We analyzed security problem discovery rate for RedHat Fedora. We find that security problems are relatively rare, their rate of discovery appears to be relatively constant under “normal” (non-attack) conditions. Discovery process often appears to satisfy Poisson assumption opening doors to use of classical reliability models. We illustrated using Yamada S-shaped model fit to v15 that in some cases such models may be effective in predicting the number of remaining security problems, and thus may offer a way of assessing security “quality” of the software product (although not necessarily its behavior under an attack).

Platform as a Service (PaaS) provides middleware resources to cloud customers. As demand for PaaS services increases, so do concerns about the security of PaaS. This paper discusses principal PaaS security and integrity requirements, and vulnerabilities and the corresponding countermeasures. We consider three core cloud elements—multi-tenancy, isolation, and virtualization and how they relate to PaaS services and security trends and concerns such as user and resource isolation, side-channel vulnerabilities in multi-tenant environments, and protection of sensitive data.

Cyber-attacks and breaches are often detected too late to avoid damage. While "classical" reactive cyber defenses usually work only if we have some prior knowledge about the attack methods and "allowable" patterns, properly constructed redundancy-based anomaly detectors can be more robust and often able to detect even zero day attacks. They are a step toward an oracle that uses knowable behavior of a healthy system to identify abnormalities. In the world of Internet of Things (IoT), security, and anomalous behavior of sensors and other IoT components, will be orders of magnitude more difficult unless we make those elements security aware from the start. In this article we examine the ability of redundancy-based anomaly detectors to recognize some high-risk and difficult to detect attacks on web servers---a likely management interface for many IoT stand-alone elements. In real life, it has taken long, a number of years in some cases, to identify some of the vulnerabilities and related attacks. We discuss practical relevance of the approach in the context of providing high-assurance Web-services that may belong to autonomous IoT applications and devices.

The goal of this roadmap paper is to summarize the stateof-the-art and identify research challenges when developing, deploying and managing self-adaptive software systems. Instead of dealing with a wide range of topics associated with the field, we focus on four essential topics of self-adaptation: design space for self-adaptive solutions, software engineering processes for self-adaptive systems, from centralized to decentralized control, and practical run-time verification & validation for self-adaptive systems. For each topic, we present an overview, suggest future directions, and focus on selected challenges. This paper complements and extends a previous roadmap on software engineering for self-adaptive systems published in 2009 covering a different set of topics, and reflecting in part on the previous paper. This roadmap is one of the many results of the Dagstuhl Seminar 10431 on Software Engineering for Self-Adaptive Systems, which took place in October 2010.

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.