M-STAR: A Modular, Evidence-based Software Trustworthiness Framework

Despite years of intensive research in the field of software vulnerabilities discovery, exploits are becoming ever more common. Consequently, it is more necessary than ever to choose software configurations that minimize systems' exposure surface to these threats. In order to support users in assessing the security risks induced by their software configurations and in making informed decisions, we introduce M-STAR, a Modular Software Trustworthiness ARchitecture and framework for probabilistically assessing the trustworthiness of software systems, based on evidence, such as their vulnerability history and source code properties. Integral to M-STAR is a software trustworthiness model, consistent with the concept of computational trust. Computational trust models are rooted in Bayesian probability and Dempster-Shafer Belief theory, offering mathematical soundness and expressiveness to our framework. To evaluate our framework, we instantiate M-STAR for Debian Linux packages, and investigate real-world deployment scenarios. In our experiments with real-world data, M-STAR could assess the relative trustworthiness of complete software configurations with an error of less than 10%. Due to its modular design, our proposed framework is agile, as it can incorporate future advances in the field of code analysis and vulnerability prediction. Our results point out that M-STAR can be a valuable tool for system administrators, regular users and developers, helping them assess and manage risks associated with their software configurations.Comment: 18 pages, 13 figure

Security in mobile agent systems: an approach to protect mobile agents from malicious host attacks

Mobile agents are autonomous programs that roam the Internet from machine to machine under their own control on behalf of their users to perform specific pre-defined tasks. In addition to that, a mobile agent can suspend its execution at any point; transfer itself to another machine then resume execution at the new machine without any loss of state. Such a mobile model can perform many possible types of operations, and might carry critical data that has to be protected from possible attacks. The issue of agent security and specially agent protection from host attacks has been a hot topic and no fully comprehensive solution has been found so far. In this thesis, we examine the possible security attacks that hosts and agents suffer from. These attacks can take one of four possible forms: Attacks from host to host, from agents to hosts, from agents to agents (peer to peer) and finally from hosts to agents. Our main concern in this thesis is these attacks from a malicious host on an agent. These attacks can take many forms including rerouting, spying out code, spying out data, spying out control flow, manipulation of code, manipulation of data, manipulation of control flow, incorrect execution of code, masquerading and denial of execution. In an attempt to solve the problem of malicious host attacks on agents, many partial solutions were proposed. These solutions ranged across simple legal protection, hardware solutions, partitioning, replication and voting, components, self-authentication, and migration history. Other solutions also included using audit logs, read-only state, append only logs, encrypted algorithms, digital signatures, partial result authentication codes, and code mess-up, limited life time of code and data as well as time limited black box security. In this thesis, we present a three-tier solution. This solution is a combination of code mess up, encryption and time out. Choosing code mess-up as part of the solution was due to the several strengths of this method that is based on obfuscating the features of the code so that any attacker will find it very difficult to understand the original code. A new algorithm iii was developed in this thesis to implement code mess-up that uses the concept of variable disguising by altering the values of strings and numerical values. Several encryption algorithms were studied to choose the best algorithm to use in the development of the proposed solution. The algorithms studied included DES, LUCIFER, MADRYGA, NEWDES, FEAL, REDOC, LOKI, KHUFU & KHAFRE, IDEA and finally MMB. The algorithm used was the DES algorithm due to several important factors including its key length. Not any language can be used to implement mobile agents. Candidate languages should possess the portability characteristic and should be safe and secure enough to guarantee a protection for the mobile agent. In addition to that the language should be efficient in order to minimize the implementation overhead and the overhead of providing safety and security. Languages used to implement mobile agents include Java, Limbo, Telescript, and Safe TCL. The Java language was chosen as the programming language for this thesis due to its high security, platform independence, and multithreading. This is in addition to several powerful features that characterize the Java language as will be mentioned later on. Implementing a mobile agent requires the assistance of a mobile agent system that helps in launching the agent from one host to another. There are many existing agent launching systems like Telescript, Aglets, Tacoma, Agent TCL and Concordia. Concordia was chosen to be the implementation tool used to launch our mobile agent. It is a software framework for developing, running and administering mobile agents, and it proved to be very efficient, and effective. The results of our proposed solutions showed the strength of the proposed model in terms of fully protecting the mobile agent from possible malicious host attacks. The model could have several points of enhancements. These enhancements include changing the code mess-up algorithm to a more powerful one, using a different encryption technique, and implementing an agent re-charge mechanism to recharge the agent after it is timeout

Towards a trustworthness model for Open Source software.

Trustworthiness is one of the main aspects that contribute to the adoption/rejection of a software product. This is actually true for any product in general, but it is especially true for Open Source Software (OSS), whose trustworthiness is sometimes still regarded as not as guaranteed as that of closed source products. Only recently, several industrial software organizations have started investigating the potential of OSS products as users or even producers. As they are now getting more and more involved in the OSS world, these software organizations are clearly interested in ways to assess the trustworthiness of OSS products, so as to choose OSS products that are adequate for their goals and needs. Trustworthiness is a major issue when people and organizations are faced with the selection and the adoption of new software. Although some ad-hoc methods have been proposed, there is not yet general agreement about which software characteristics contribute to trustworthiness. Such methods \u2013like the OpenBQR [30] and other similar approaches [58][59]\u2013 assess the trustworthiness of a software product by means of a weighted sum of specific quality evaluations. None of the existing methods based on weighted sums has been widely adopted. In fact, these methods are limited in that they typically leave the user with two hard problems, which are common to models built by means of weighted sums: identify the factors that should be taken into account, and assign to each of these factors the \u201ccorrect\u201d weight to adequately quantify its relative importance. Therefore, this work focuses on defining an adequate notion of trustworthiness of Open Source products and artifacts and identifying a number of factors that influence it to help and guide both developers and users when deciding whether a given program (or library or other piece of software) is \u201cgood enough\u201d and can be trusted in order to be used in an industrial or professional context. The result of this work is a set of estimation models for the perceived trustworthiness of OSS. This work has been carried out in the context of the IST project QualiPSo (http://www.qualipso.eu/), funded by the EU in the 6th FP (IST-034763). The first step focuses on defining an adequate notion of trustworthiness of software products and artifacts and identifying a number of factors that influence it. The definition of the trustworthiness factors is driven by specific business goals for each organization. So, we carried out a survey to elicit these goals and factors directly from industrial players, trying to derive the factors from the real user needs instead of deriving them from our own personal beliefs and/or only by reading the available literature. The questions in the questionnaire were mainly classified in three different categories: 1) Organization, project, and role. 2) Actual problems, actual trustworthiness evaluation processes, and factors. 3) Wishes. These questions are needed to understand what information should be available but is not, and what indicators should be provided for an OSS product to help its adoption. To test the applicability of the trustworthiness factors identified by means of the questionnaires, we selected a set of OSS projects, widely adopted and generally considered trustable, to be used as references. Afterwards, a first quick analysis was carried out, to check which factors were readily available on each project\u2019s web site. The idea was to emulate the search for information carried out by a potential user, who browses the project\u2019s web sites, but is not willing to spend too much effort and time in carrying out a complete analysis. By analyzing the results of this investigation, we discovered that most of the trustworthiness factors are not generally available with information that is enough to make an objective assessment, although some factors have been ranked as very important by the respondents of our survey. To fill this gap, we defined a set of different proxy-measures to use whenever a factor cannot be directly assessed on the basis of readily available information. Moreover, some factors are not measurable if developers do not explicitly provide essential information. For instance, this happens for all factors that refer to countable data (e.g., the number of downloads cannot be evaluated in a reliable way if the development community does not publish it). Then, by taking into account the trustworthiness factors and the experience gained through the project analysis, we defined a Goal/Question/Metric (GQM[29]) model for trustworthiness, to identify the qualities and metrics that determine the perception of trustworthiness by users. In order to measure the metrics identified in the GQM model, we identified a set of tools. When possible, tools were obtained by adapting, extending, and integrating existing tools. Considering that most of metrics were not available via the selected tools, we developed MacXim, a static code analysis tool. The selected tools integrate a number of OSS tools that support the creation of a measurement plan, starting from the main actors\u2019 and stakeholders\u2019 objectives and goals (developer community, user community, business needs, specific users, etc.), down to the specific static and dynamic metrics that will need to be collected to fulfill the goals. To validate the GQM model and build quantitative models of perceived trustworthiness and reliability, we collected both subjective evaluations and objective measures on a sample of 22 Java and 22 C/C++ OSS products. Objective measures were collected by means of MacXim and the other identified tools while subjective evaluations were collected by means of more than 500 questionnaires. Specifically, the subjective evaluations concerned how users evaluate the trustworthiness, reliability and other qualities of OSS; objective measures concerned software attributes like size, complexity, modularity, and cohesion. Finally, we correlated the objective code measures to users\u2019 and developers\u2019 evaluations of OSS products. The result is a set of quantitative models that account for the dependence of the perceivable qualities of OSS on objectively observable qualities of the code. Unlike the models based on weighted sums usually available in the literature, we have obtained estimation models [87], so the relevant factors and their specific weights are identified via statistical analysis, and not in a somewhat more subjective way, as usually happens. Qualitatively, our results may not be totally surprising. For instance, it may be generally expected that bigger and more complex products are less trustworthy than smaller and simpler products; likewise, it is expected that well modularized products are more reliable. For instance, our analyses indicate that the OSS products are most likely to be trustworthy if: \u2022 Their size is not greater than 100,000 effective LOC; \u2022 The number of java packages is lower than 228. These models derived in our work can be used by end-users and developers that would like to evaluate the level of trustworthiness and reliability of existing OSS products and components they would like to use or reuse, based on measurable OSS code characteristics. These models can also be used by the developers of OSS products themselves, when setting code quality targets based on the level of trustworthiness and reliability they want to achieve. So, the information obtained via our models can be used as an additional piece of information that can be used when making informed decisions. Thus, unlike several discussions that are based on \u2013sometimes interested\u2013 opinions about the quality of OSS, this study aims at deriving statistically significant models that are based on repeatable measures and user evaluations provided by a reasonably large sample of OSS users. The detailed results are reported in the next sections as follows: \u2022Chapter 1 reports the introduction to this work \u2022Chapter 2 reports the related literature review \u2022Chapter 3 reports the identified trustworthiness factors \u2022Chapter 4 describe how we built the trustworthiness model \u2022Chapter 5 shows the tools we developed for this activity \u2022Chapter 6 reports on the experimentation phase \u2022Chapter 7 shows the results of the experimentation \u2022Chapter 8 draws conclusions and highlights future works \u2022Chapter 9 lists the publication made during the Ph