Abstract The choice of one’s programming language and relative ecosystem of libraries can affect the likelihood of encountering a critical vulnerability. Simply counting the vulnerabilities by mining a software repository is not enough, and case-control studies are a well-accepted methodology to determine relative risk. Yet, they require the ability to compare ‘equals with equals’ as a library for text processing is likely subject to less security scrutiny than a library for web applications. To compare libraries, we implemented a human-guided protocol to transfer classification categories from an ecosystem to libraries of another ecosystem. By building of this categorization, we performed a case-control study with the vulnerabilities available on Snyk and with status ’reviewed’ in the Github security Advisories till 2024. We mapped 76 Java/Maven libraries and 221 Python/PyPI packages as ’cases’ (libraries with vulnerabilities with a CVSS critical score) compared them against 58 Java/Maven and 166 Python/PyPI ’controls’ (Only with a high CVSS score). We found and overall the odds ratio of ending with a critical vulnerability is slightly higher when using a Java/Maven library in comparison to using a Python/PyPi package (1.13x). We refine the analysis to understand possible reasons for our result by using the CVSS vector metric. A possible explanation is that a vulnerability with low attack complexity has disproportionately higher chances to be critical in Java/Maven (38.9x) than in Python/PyPI (5.9x). Such results might be explained by the lack of past security interest in the Python ecosystem. By using the introduction of the OWASP dependency checker in 2023 for Python as possible indication of community interest, we found a risk reversal: after 2023 the risk of ending with a critical vulnerability (as opposed to just a high severity one) is significantly higher (2.4x) for a Python/PyPI package than for a Java/Maven library. To allow replication and updates, we make the dataset and the protocol individual steps available as open data.

Quantitative vulnerability assessment is central to security management, guiding how risks are prioritized and mitigated. Yet, severity scoring relies on human judgment and is therefore subject to differences in experience, interpretation, and diligence; prior work has even shown expert disagreement. We examine an NLP-based assistive tool that visualizes keyword cues during assessment. In a controlled survey of 389 participants recruited via Amazon MTurk and Prolific, we statistically analyze how participant skills/demographics, vulnerability characteristics, and tool support affect outcomes. Results show the tool does not consistently improve assessment accuracy across expertise levels, but can help for specific vulnerability types (e.g., CWE-787) and CVSS metrics (AC, PR, Scope), and can increase user confidence. Beyond immediate performance, the tool can support training for manual assessment tasks that are hard to automate, as learning effects yield significant improvements on subsequent tasks. This work informs the design of cybersecurity decision-support tools and motivates future research on security training and human-centered security.

[Background:] Thematic analysis of free-text justifications in human experiments provides significant qualitative insights. Yet, it is costly because reliable annotations require multiple domain experts. Large language models (LLMs) seem ideal candidates to replace human annotators. [Problem:] Coding security-specific aspects (code identifiers mentioned, lines-of-code-mentioned, security keywords mentioned) may require deeper contextual understanding than sentiment classification. [Objective:] explore whether LLMs can act as automated annotators for technical security comments by human subjects. [Method:] We prompt four best LLMs on LiveBench to detect nine security-relevant codes in free-text comments by human subjects analyzing vulnerable code snippets. Outputs are compared to the human annotators along with Cohen’s Kappa (chance-corrected accuracy). We test different prompts mimicking annotation best practices: emerging codes, a detailed codebook with examples, and conflicting examples. [Negative Results:] We observed marked improvements only with the code descriptions, but they are not uniform across codes and not sufficient to reliably replace a human annotator. [Limitations:] Additional studies with more LLMs and annotation tasks are needed.

Goal: Machine learning (ML) has been proposed to identify security fixing commits with mixed success. We evaluate a different alternative in which expert-defined common sense rules with power-law weights are used to identify security fixing commit. Experiments: We first evaluated how those rules perform against ML models trained on the same features on which rules are based on the ProjectKB real world dataset of Java security commits. We then ran a think aloud protocol with seven senior analysts to analyze whether the selected rules are consistent with usage. Lastly, we ran the experiment with Master students ([Formula: see text]) to check whether the last ranking or the actual mention of which rules were applicable is beneficial to users with less experience. We found that the common-sense rules defined by security experts have a similar performance to classical ML approaches. Findings: Using Shap values to explain earned features, we find that ML models have the same chance corrected accuracy of expert defined rules, and they learned essentially the same top features identified by the experts and only differs on minor features (either among themselves and between the expert features). We observed that the juniors performance are comparable to the experts' one (CI [0.62, 0.76]). When asked to junior analysts to identify the fixing commits (in the top 10 selected by the tool) showing them which features was responsible for the selection do not seem to help (when compared with a control group with no support). A conclusion of our study is that one might just use ML to first analyze the data and then distill common sense rules that are still effective to apply. More experiments are needed to make features useful for the final decision.

The advent of Infrastructure-as-Code (IaC) and cloud platforms has transformed applications into ephemeral deployments of configuration files, where containers live for only a few minutes. Several industry-level static analyzers are available to check security misconfigurations before deployment, but the experimental evidence that we report in this paper is that they provide different and possibly inconsistent results. We developed an automated pipeline to evaluate and compare static analyzers for Helm charts, a popular package manager to deploy Kubernetes (K8s) applications, in finding a functional configuration adhering to the principle of least privilege. We evaluated seven open-source chart analyzer tools on the 60 most common Artifact Hub Helm charts (returned by the Application Programming Interface — API upon first invocation) and found that overly permissive ClusterRoles are the most common misconfiguration, and using a high user ID is the most commonly needed permission. During the evaluation, we also found several bugs, both false positives and negatives, that we reported to the tool developers. Securing cloud configurations still requires significant manual intervention, and more effort should be spent on standardizing the analysis of misconfiguration.

The 5G core network is the backbone of modern mobile communication, providing high-speed, low-latency, and diverse services for users and industries. Artificial Intelligence (AI) plays an important role in this network by optimizing per-formance, supporting dynamic resource scaling, and improving security through anomaly detection and threat mitigation. Testing AI in 5G environments is difficult because of the complexity of the network and the many possible attack vectors. In this paper, we present a modular and reproducible testbed for evaluating AI-based security mechanisms in the 5G core. The testbed emulates key 5G components and traffic patterns, enabling systematic experiments under realistic conditions. It also provides reliable measurements of Key Performance Indicators (KPIs) to evaluate the effectiveness, robustness, and operational impact of AI solutions, including their ability to detect and mitigate threats. Our work provides a structured framework for testing AI solutions and supports the development of secure, resilient, and AI -enhanced 5G networks.

National intelligence agencies have the complex task of investigating threats to the national security within strict legal and policy frameworks. Reconstructing the context of investigative decisions for post-analysis and compliance checks is prone to error and labour-intensive. To address this, we propose to capture decision-making processes and their rationale directly using an OWL-based ontology. This approach overcomes the limitations of traditional data management and existing decision ontologies in handling the intricate data dependencies within threat intelligence (TI) decision-making. The result is the Threat Intelligence Decision Ontology (TIDO), which structures analysts’ decision-making while incrementally capturing a decision trace for post-analysis as investigations unfold. The ontology was developed under the complex constraints of safeguarding threat intelligence practices and case information, and validated through competency questions from intelligence experts from the Dutch Defence Intelligence and Security Service (DISS). TIDO offers a novel solution for capturing and understanding decision processes within the sensitive domain of threat intelligence, and evidence-based decision-making in general.

The GDPR was enacted to reign in the mighty corporations of the internet. Then, it was unleashed on all organizations, large and small alike. We report the results of a multi-site field study on Italian schools, and the challenges they face to implement the GDPR while running activities full of sensitive issues without an army of legal and compliance officers. The sample study consisted of one kindergarten, ten primary schools, two junior secondary schools, and two secondary schools. We did not find evidence of the privacy paradox (spotless on paper but careless on the field). In contrast, school staff mostly crumble when by-the-book procedures cannot be implemented with the resources that they actually have. We discuss what happen on the field, from critical privacy incidents with potential impact on pupils security and safety, to ‘formal’ privacy incidents for which life is too short to bother-and how a risk-based approach could address them.

Threat analysis is a pillar of security-by-design which plays an important role in the elicitation and refinement of security threats. In preparation for the analysis, a model of the system under analysis e.g., the Data Flow Diagram (DFD for short) is often created. Empirical measures of success are important for practitioners that are struggling to meet the current demands for expertise. But no previous work has investigated the role of these diagrams during the validation of identified security threats. This paper presents an experiment conducted with 98 students in two countries. We measured the impact of the DFD on the perceived and actual effectiveness of validating a list of identified security threats including both fabricated and actual threats. In presence of sequence diagrams, the participants perceived DFDs as more useful. However, when exposed to both a DFD and a sequence diagram, DFDs had no significant impact on the participants’ ability to validate security threats.

Helm is a package manager that allows defining, installing, and upgrading applications with Kubernetes (K8s), a popular container orchestration platform. A Helm chart is a collection of files describing all dependencies, resources, and parameters required for deploying an application within a K8s cluster. This study aimed to mine and empirically evaluate the security of Helm charts, comparing the performance of existing tools in terms of misconfigurations reported by policies available by default, and measuring to what extent LLMs could be used for removing misconfigurations. For these reasons, we proposed a pipeline to mine Helm charts from Artifact Hub, a popular centralized repository, and analyze them using state-of-the-art open-source tools like Checkov and KICS. First, the pipeline runs several chart analyzers and identifies the common and unique misconfigurations reported by each tool. Secondly, it uses LLMs to suggest a mitigation for each misconfiguration. Finally, the LLM refactored chart previously generated is analyzed again by the same tools to see whether it satisfies the tool's policies. We also performed a manual analysis on a subset of charts to evaluate whether there are false positive misconfigurations from the tool's reporting and in the LLM refactoring. We found that (i) there is a significant difference between LLMs, (ii) providing a snippet of the YAML template as input might be insufficient compared to all resources, and (iii) even though LLMs can generate correct fixes, they may also delete other irrelevant configurations that break the application.

Abstract Slicing is a fault localization technique that has been proposed to support debugging and program comprehension. Yet, its empirical effectiveness during code inspection by humans has received limited attention. The goal of our study is two-fold. First, we aim to define what it means for a code reviewer to identify the vulnerable lines correctly. Second, we investigate whether reducing the number of to-be-inspected lines by method-level slicing supports code reviewers in detecting security vulnerabilities. We propose a novel approach based on the notion of a $$\delta $$ δ -neighborhood (intuitively based on the idea of the context size of the command ) to define correctly identified lines. Then, we conducted a multi-year controlled experiment (2017-2023) in which MSc students attending security courses ( $$n=236$$ n = 236 ) were tasked with identifying vulnerable lines in original or sliced Java files from Apache Tomcat. We provide perfect seed lines for a slicing algorithm to control for confounding factors. Each treatment differs in the pair (Vulnerability, Original/Sliced) with a balanced design with vulnerabilities from the OWASP Top 10 2017: A1 (Injection), A5 (Broken Access Control), A6 (Security Misconfiguration), and A7 (Cross-Site Scripting). To generate smaller slices for human consumption, we used a variant of intra-procedural thin slicing. We report the results for $$\delta = 0$$ δ = 0 which corresponds to exactly matching the vulnerable ground truth lines, and $$\delta = 3$$ δ = 3 which represents the scenario of identifying the vulnerable area. For both cases, we found that slicing helps in ‘finding something’ (the participant has found at least some vulnerable lines) as opposed to ‘finding nothing’. For the case of $$\delta = 0$$ δ = 0 analyzing a slice and analyzing the original file are statistically equivalent from the perspective of lines found by those who found something. With $$\delta = 3$$ δ = 3 slicing helps to find more vulnerabilities compared to analyzing an original file, as we would normally expect. Given the type of population, additional experiments are necessary to be generalized to experienced developers.

We design and implement PG, a Byzantine fault-tolerant and privacy-preserving multi-sensor fusion system. PG is flexible and extensible, supporting a variety of fusion algorithms and application scenarios.

Following the recent release of AI assistants, such as OpenAI's ChatGPT and GitHub Copilot, the software industry quickly utilized these tools for software development tasks, e.g., generating code or consulting AI for advice. While recent research has demonstrated that AI-generated code can contain security issues, how software professionals balance AI assistant usage and security remains unclear. This paper investigates how software professionals use AI assistants in secure software development, what security implications and considerations arise, and what impact they foresee on secure software development. We conducted 27 semi-structured interviews with software professionals, including software engineers, team leads, and security testers. We also reviewed 190 relevant Reddit posts and comments to gain insights into the current discourse surrounding AI assistants for software development. Our analysis of the interviews and Reddit posts finds that despite many security and quality concerns, participants widely use AI assistants for security-critical tasks, e.g., code generation, threat modeling, and vulnerability detection. Their overall mistrust leads to checking AI suggestions in similar ways to human code, although they expect improvements and, therefore, a heavier use for security tasks in the future. We conclude with recommendations for software professionals to critically check AI suggestions, AI creators to improve suggestion security and capabilities for ethical security tasks, and academic researchers to consider general-purpose AI in software development.

Abstract Security vulnerability fixes could be a promising research avenue for Automated Program Repair (APR) techniques. In recent years, APR tools have been thoroughly developed for fixing generic bugs. However, the area is still relatively unexplored when it comes to fixing security bugs or vulnerabilities. In this paper, we evaluate nine state-of-the-art APR tools and one vulnerability-specific repair tool. In particular, we investigate their ability to generate patches for 79 real-world Java vulnerabilities in the Vul4J dataset, as well as the level of trustworthiness of these patches. We evaluate the tools with respect to their ability to generate security patches that are (i) testable, (ii) having the positive effect of closing the vulnerability, and (iii) not having side effects from a functional point of view. Our results show that the evaluated APR tools were able to generate testable patches for around 20% of the considered vulnerabilities. On average, nearly 73% of the testable patches indeed eliminate the vulnerabilities, but only 44% of them could actually fix security bugs while maintaining the functionalities. To understand the root cause of this phenomenon, we conduct a detailed comparative study of the general bug fix patterns in Defect4J and the vulnerability fix patterns in ExtraVul (which we extend from Vul4J). Our investigation shows that, although security patches are short in terms of lines of code, they contain unique characteristics in their fix patterns compared to general bugs. For example, many security fixes require adding method calls. These method calls contain specific input validation-related keywords, such asencode,normalize, andtrim. In this regard, our study suggests that additional repair patterns should be implemented for existing APR tools to fix more types of security vulnerabilities.

Abstract Objective We investigated whether (possibly wrong) security patches suggested by Automated Program Repairs (APR) for real world projects are recognized by human reviewers. We also investigated whether knowing that a patch was produced by an allegedly specialized tool does change the decision of human reviewers. Method We perform an experiment with $$n= 72$$ n = 72 Master students in Computer Science. In the first phase, using a balanced design, we propose to human reviewers a combination of patches proposed by APR tools for different vulnerabilities and ask reviewers to adopt or reject the proposed patches. In the second phase, we tell participants that some of the proposed patches were generated by security-specialized tools (even if the tool was actually a ‘normal’ APR tool) and measure whether the human reviewers would change their decision to adopt or reject a patch. Results It is easier to identify wrong patches than correct patches, and correct patches are not confused with partially correct patches. Also patches from APR Security tools are adopted more often than patches suggested by generic APR tools but there is not enough evidence to verify if ‘bogus’ security claims are distinguishable from ‘true security’ claims. Finally, the number of switches to the patches suggested by security tool is significantly higher after the security information is revealed irrespective of correctness. Limitations The experiment was conducted in an academic setting, and focused on a limited sample of popular APR tools and popular vulnerability types.

Context: Experimentation in Software and Security Engineering is a common research practice, in particular with human subjects.Problem: The combinatorial nature of software configurations and the difficulty of recruiting experienced subjects or running complex and expensive experiments make the use of full factorial experiments unfeasible to obtain statistically significant results.Contribution: Provide comprehensive alternative Designs of Experiments (DoE) based on orthogonal designs or crossover designs that provably meet desired requirements such as balanced pair-wise configurations or balanced ordering of scenarios to mitigate bias or learning effects.We also discuss and formalize the statistical implications of these design choices, in particular for crossover designs.Artifact: We made available the algorithmic construction of the design for 𝓁 = 2, 3, 4, 5 levels for arbitrary 𝐾 factors and illustrated their use with examples from security and software engineering research.

The behavior of enterprise users (e.g. browsing at night or visiting gambling sites) is a potential factor that might increase the chances of malware encounters (e.g. coinminers vs ransomware) on the field. We report a case-control study on telemetry data collected by Trend Micro, a global cybersecurity vendor, to identify users’ behavioral characteristics that can be used to differentiate cybersecurity risks profiles. Our results show that different types of ‘patients zero’ are vulnerable to different types of epidemics. The odds ratio of encountering malware such as PUAs, trojans, and hacktools is higher for a variety of network and system behavior (e.g. number, types, and diversity of visited web sites, visit of gambling sites, etc.) but it is not significant for other factors such as browsing at night. Other type of malware such as coinminers have an increase in the odds ratio only for few type of factors (e.g. gambling web sites). We also present a specific methodology tailored for investigating self-propagating malware such as ransomware in which one is infected by one’s neighbor. With this approach, we observed a more accurate characterization of the odds of encountering ransomware based on system-based behaviors than with a standard case-control study setup. Experiments with different vendors may be needed to generalize the results and offset potential bias due to differences in market share.

To address the issue of educating and training new experts in cybersecurity, it is crucial to identify the specific educational needs of the various professions that exist in the field. We measure these needs by analysing six cybersecurity-related job profiles—each with its own specific skill requirements—that have been assessed by academic and industrial organisations from the cybersecurity community in 14 European countries. We find that it is possible to identify a series of “transversal” skills relevant to all job profiles, and thus of utmost importance in the cybersecurity curricula. However, we also observe that academic and industrial priorities differ substantially, and that skills related to the area of Human security do not rank particularly high, possibly exposing the difficulty of integrating such concepts in traditional education.

The adoption of microservice architecture is rapidly growing, involving industries of every size. Their ability to scale and reconstitute complex functionalities into small, cohesive, and interconnected components (the microservices), and their limited use of isolation contribute to this success. Unfortunately but unsurprisingly, these very factors enlarge the attack surface and increase the security risks of today’s deployments. In this study, we performed a systematization of knowledge about the run-time security of microservices. Starting from a keyword search, we initially reviewed 807 papers available in digital libraries (e.g., Google Scholar and Scopus), which we filtered down to 48 by applying a number of selection criteria (e.g., the presence of a proof-of-concept implementation). We also considered over 30 industry tools that offer various security services for microservices. We categorized both papers and tools and highlighted areas where research is abundant, where it is lacking, and where it is misleading. We conclude that the run-time security of microservices is still in its infancy and we supplement our analyses with insights into addressing the key challenges.

Abstract Security risk analysis (SRA) is a key activity in software engineering but requires heavy manual effort. Community knowledge in the form of security patterns or security catalogs can be used to support the identification of threats and security controls. However, no evidence-based theory exists about the effectiveness of security catalogs when used for security risk analysis. We adopt a grounded theory approach to propose a conceptual, revised and refined theory of SRA knowledge reuse. The theory refinement is backed by evidence gathered from conducting interviews with experts (20) and controlled experiments with both experts (15) and novice analysts (18). We conclude the paper by providing insights into the use of catalogs and managerial implications.

Abstract Context: Technical leverage is the ratio between dependencies (other people’s code) and own codes of a software package. It has been shown to be useful to characterize the Java ecosystem and there are also studies on the NPM ecosystem available. Objective: By using this metric we aim to analyze the Python ecosystem, how it evolves, and how secure it is, as a developer would perceive it when deciding to adopt or update (or not) a library. Method: We collect a dataset of the top 600 Python packages (corresponding to 21,205 versions) and used a number of innovative approaches for its analysis including the use of a two-part statistical model to deal with excess zeros, a mathematical closed formulation to estimate vulnerabilities that we confirm with bootstrapping on the actual dataset. Results: Small Python package versions have a median technical leverage of 6.9x their own code, while bigger package versions rely on dependencies code a tenth of their own (median leverage of 0.1). In terms of evolution, Python packages tend to have stable technical leverage through their evolution (once highly leveraged, always leveraged). On security, the chance of getting a safe package version when choosing a package is actually better than previous research has shown based on the ratio of safe package versions in the ecosystem. Coclusions: Python packages ship a lot of other people’s code and tend to keep doing so. However, developers will have a good chance to choose a safe package version.

Researchers analyze underground forums to study abuse and cybercrime activities. Due to the size of the forums and the domain expertise required to identify criminal discussions, most approaches employ supervised machine learning techniques to automatically classify the posts of interest. Human annotation is costly. How to select samples to annotate that account for the structure of the forum? We present a methodology to generate stratified samples based on information about the centrality properties of the population and evaluate classifier performance. We observe that by employing a sample obtained from a uniform distribution of the post degree centrality metric, we maintain the same level of precision but significantly increase the recall (+30%) compared to a sample whose distribution is respecting the population stratification. We find that classifiers trained with similar samples disagree on the classification of criminal activities up to 33% of the time when deployed on the entire forum.

Software updates reduce the opportunity for exploitation. However, since updates can also introduce breaking changes, enterprises face the problem of balancing the need to secure software with updates with the need to support operations. We propose a methodology to quantitatively investigate the effectiveness of software updates strategies against attacks of Advanced Persistent Threats (APTs). We consider strategies where the vendor updates are the only limiting factors to cases in which enterprises delay updates from 1 to 7 months based on SANS data. Our manually curated dataset of APT attacks covers 86 APTs and 350 campaigns from 2008 to 2020. It includes information about attack vectors, exploited vulnerabilities (e.g., 0-days versus public vulnerabilities), and affected software and versions. Contrary to common belief, most APT campaigns employed publicly known vulnerabilities. If an enterprise could theoretically update as soon as an update is released, it would face lower odds of being compromised than those waiting one (4.9x) or three (9.1x) months. However, if attacked, it could still be compromised from 14% to 33% of the times. As in practice enterprises must do regression testing before applying an update, our major finding is that one could perform 12% of all possible updates restricting oneself only to versions fixing publicly known vulnerabilities without significant changes to the odds of being compromised compared to a company that updates for all versions.

Program slicing has been used to semi- or fully-automatically help developers find errors and vulnerabilities in their programs. For example, Dashevskyi et al. (IEEE TSE 2018) introduced a lightweight slicer for Java that can be used for vulnerability analysis. However, a similar lightweight slicer for C/C++ is still missing. In this work we propose a comparison method for parsers, evaluate it on two commonly-used parsers, and develop a lightweight slicer for C/C++ using the “better” parser from our comparison. From our evaluation, the Joern parsing method (island grammar) could parse non-standard C/C++ code but its resulting structure may contain semantic errors that can affect subsequent analysis. ANTLR4 is faster in returning a result, and when manually cleared of non-standard C/C++ codes, it is more accurate than Joern. We then built our C/C++ thin slicer extension using ANTLR4, and we observed that it is promising from both precision and performance perspectives. As a future work, we plan to improve the logic behind processing pointers. In particular, we consider doing deeper pointer analysis.

Open-source packages typically have their source code available on a source code repository (e.g., on GitHub), but developers prefer to use pre-built artifacts directly from the package repositories (such as npm for JavaScript). Between the source code and the distributed artifacts, there could be differences that pose security risks (e.g., attackers deploy malicious code during package installation) in the software supply chain. Existing package scanners focus on the entire artifact of a package to detect this kind of attacks. These procedures are not only time consuming, but also generate high irrelevant alerts (FPs). An approach called LastPyMile by Vu et al. (ESEC/FSE’21) has been shown to be effective in detecting discrepancies and reducing false alerts in vetting Python packages on PyPI by focusing only on the differences between the source and the package. In this work, we propose to port that approach to scan JavaScript packages in the npm ecosystem. We presented a preliminary evaluation of our implementation on a set of real malicious npm packages and the top popular packages. The results show that while being 20.7x faster than git-log approach, our approach managed to reduce the percentage of false alerts produced by package scanner by 69%.

Securing cloud configurations is an elusive task, which is left up to system administrators who have to base their decisions on "trial and error" experimentations or by observing good practices (e.g., CIS Benchmarks). We propose a knowledge, AND/OR, graphs approach to model cloud deployment security objects and vulnerabilities. In this way, we can capture relationships between configurations, permissions (e.g., CAP_SYS_ADMIN), and security profiles (e.g., AppArmor and SecComp). Such an approach allows us to suggest alternative and safer configurations, support administrators in the study of what-if scenarios, and scale the analysis to large scale deployments. We present an initial validation and illustrate the approach with three real vulnerabilities from known sources.

The use of container and orchestration technologies, such as Docker and Kubernetes keeps growing every year. For the purpose of security experimentation and reproducibility of security attacks and defenses, an open-source testbed would also be an important step forward. Yet, while several security experimentation testbeds from web application testing to capture-the-flag (CTF) competitions have been proposed, a similar solution for cloud experiments is wanting. To fill this gap, we propose an open-source cloud testbed that, by using Domain Specific Language (DSL) files (e.g. with JSON or YAML syntax), allows defining experimentation scenarios as configuration files. Using DSL files allows to create, share, customize, automatically deploy, and reproduce different scenarios in a user-friendly manner. We describe the design and the corresponding tools and technologies for different implementations.

Abstract Due to the lack of established real-world benchmark suites for static taint analyses of Android applications, evaluations of these analyses are often restricted and hard to compare. Even in evaluations that do use real-world apps, details about the ground truth in those apps are rarely documented, which makes it difficult to compare and reproduce the results. To push Android taint analysis research forward, this paper thus recommends criteria for constructing real-world benchmark suites for this specific domain, and presents TaintBench, the first real-world malware benchmark suite with documented taint flows. TaintBench benchmark apps include taint flows with complex structures, and addresses static challenges that are commonly agreed on by the community. Together with the TaintBench suite, we introduce the TaintBench framework, whose goal is to simplify real-world benchmarking of Android taint analyses. First, a usability test shows that the framework improves experts’ performance and perceived usability when documenting and inspecting taint flows. Second, experiments using TaintBench reveal new insights for the taint analysis tools Amandroid and FlowDroid: (i) They are less effective on real-world malware apps than on synthetic benchmark apps. (ii) Predefined lists of sources and sinks heavily impact the tools’ accuracy. (iii) Surprisingly, up-to-date versions of both tools are less accurate than their predecessors.

A recent trend in multi-party computation is to achieve cryptographic fairness via monetary penalties, i.e. each honest player either obtains the output or receives a compensation in the form of a cryptocurrency. We pioneer another type of fairness, financial fairness, that is closer to the real-world valuation of financial transactions. Intuitively, a penalty protocol is financially fair if the net present cost of participation (the total value of cash inflows less cash outflows, weighted by the relative discount rate) is the same for all honest participants, even when some parties cheat. We formally define the notion, show several impossibility results based on game theory, and analyze the practical effects of (lack of) financial fairness if one was to run the protocols for real on Bitcoin using Bloomberg’s dark pool trading. For example, we show that the ladder protocol (CRYPTO’14), and its variants (CCS’15 and CCS’16), fail to achieve financial fairness both in theory and in practice, while the penalty protocols of Kumaresan and Bentov (CCS’14) and Baum, David and Dowsley (FC’20) are financially fair.

The Internet of Things (IoT) revolutionised the way devices, and human beings, cooperate and interact. The interconnectivity and mobility brought by IoT devices led to extremely variable networks, as well as unpredictable information flows. In turn, security proved to be a serious issue for the IoT, far more serious than it has been in the past for other technologies. We claim that IoT devices need detailed descriptions of their behaviour to achieve secure default configurations, sufficient security configurability, and self-configurability. In this article, we propose S×C4IoT, a framework that addresses these issues by combining two paradigms: Security by Contract (S×C) and Fog computing. First, we summarise the necessary background such as the basic S×C definitions. Then, we describe how devices interact within S×C4IoT and how our framework manages the dynamic evolution that naturally result from IoT devices life-cycles. Furthermore, we show that S×C4IoT can allow legacy S×C-noncompliant devices to participate with an S×C network, we illustrate two different integration approaches, and we show how they fit into S×C4IoT. Last, we implement the framework as a proof-of-concept. We show the feasibility of S×C4IoT and we run different experiments to evaluate its impact in terms of communication and storage space overhead.

Vulnerable dependencies are a known problem in today’s free open-source software ecosystems because FOSS libraries are highly interconnected, and developers do not always update their dependencies. Our paper proposes Vuln4Real, the methodology for counting actually vulnerable dependencies, that addresses the over-inflation problem of academic and industrial approaches for reporting vulnerable dependencies in FOSS software, and therefore, caters to the needs of industrial practice for correct allocation of development and audit resources. To understand the industrial impact of a more precise methodology, we considered the 500 most popular FOSS Java libraries used by SAP in its own software. Our analysis included 25767 distinct library instances in Maven. We found that the proposed methodology has visible impacts on both ecosystem view and the individual library developer view of the situation of software dependencies: Vuln4Real significantly reduces the number of false alerts for deployed code (dependencies wrongly flagged as vulnerable), provides meaningful insights on the exposure to third-parties (and hence vulnerabilities) of a library, and automatically predicts when dependency maintenance starts lagging, so it may not receive updates for arising issues.

In finance, leverage is the ratio between assets borrowed from others and one's own assets. A matching situation is present in software: by using free open-source software (FOSS) libraries a developer leverages on other people's code to multiply the offered functionalities with a much smaller own codebase. In finance as in software, leverage magnifies profits when returns from borrowing exceed costs of integration, but it may also magnify losses, in particular in the presence of security vulnerabilities. We aim to understand the level of technical leverage in the FOSS ecosystem and whether it can be a potential source of security vulnerabilities. Also, we introduce two metrics change distance and change direction to capture the amount and the evolution of the dependency on third-party libraries. The application of the proposed metrics on 8494 distinct library versions from the FOSS Maven-based Java libraries shows that small and medium libraries (less than 100KLoC) have disproportionately more leverage on FOSS dependencies in comparison to large libraries. We show that leverage pays off as leveraged libraries only add a 4% delay in the time interval between library releases while providing four times more code than their own. However, libraries with such leverage (i.e., 75% of libraries in our sample) also have 1.6 higher odds of being vulnerable in comparison to the libraries with lower leverage. We provide an online demo for computing the proposed metrics for real-world software libraries available under the following URL: https://techleverage.eu/.

Open source packages have source code available on repositories for inspection (e.g. on GitHub) but developers use pre-built packages directly from the package repositories (such as npm for JavaScript, PyPI for Python, or RubyGems for Ruby). Such convenient practice assumes that there are no discrepancies between source code and packages. These differences pose both operational risks (e.g. making dependent projects unable to compile) and security risks (e.g. deploying malicious code during package installation) in the software supply chain. Our empirical assessment of 2438 popular packages in PyPI with an analysis of around 10M lines of code shows several differences in the wild: modifications cannot be just attributed to malicious injections. Yet, scanning again all and whole ‘most likely good but modified’ packages is hard to manage for FOSS downstream users. We propose a methodology, LastPyMile, for identifying the differences between build artifacts of software packages and the respective source code repository. We show how it can be used to extend current package scanning practices for malware injection (which only covers less than 1% of the code of deployed packages).

Several large scale studies on the Maven, NPM, and Android ecosystems point out that many developers do not often update their vulnerable software libraries thus exposing the user of their code to security risks. The purpose of this study is to qualitatively investigate the choices and the interplay of functional and security concerns on the developers' overall decision-making strategies for selecting, managing, and updating software dependencies.

Increasing popularity of third-party package repositories, like NPM, PyPI, or RubyGems, makes them an attractive target for software supply chain attacks. By injecting malicious code into legitimate packages, attackers were known to gain more than 100,000 downloads of compromised packages. Current approaches for identifying malicious payloads are resource demanding. Therefore, they might not be applicable for the on-the-fly detection of suspicious artifacts being uploaded to the package repository. In this respect, we propose to use source code repositories (e.g., those in Github) for detecting injections into the distributed artifacts of a package. Our preliminary evaluation demonstrates that the proposed approach captures known attacks when malicious code was injected into PyPI packages. The analysis of the 2666 software artifacts (from all versions of the top ten most downloaded Python packages in PyPI) suggests that the technique is suitable for lightweight analysis of real-world packages.

Abstract Assessing the risks of software vulnerabilities is a key process of software development and security management. This assessment requires to consider multiple factors (technical features, operational environment, involved assets, status of the vulnerability lifecycle, etc.) and may depend from the assessor’s knowledge and skills. In this work, we tackle with an important part of this problem by measuring the accuracy oftechnicalvulnerability assessments by assessors with different level and type of knowledge. We report an experiment to compare how accurately students with different technical education and security professionals are able to assess the severity of software vulnerabilities with the Common Vulnerability Scoring System (v3) industry methodology. Our results could be useful for increasing awareness about the intrinsic subtleties of vulnerability risk assessment and possibly better compliance with regulations. With respect to academic education, professional training and human resources selections our work suggests that measuring the effects of knowledge and expertise on the accuracy of software security assessments is feasible albeit not easy.

The popularity of the JavaScript programming language for server-side programming has increased tremendously over the past decade. The Node.js framework is a popular JavaScript server-side framework with an efficient runtime for cloud-based event-driven architectures. One of its strengths is the presence of thousands of third-party libraries which allow developers to quickly build and deploy applications. These very libraries are a source of security threats as a vulnerability in one library can (and in some cases did) compromise an entire server. In order to support the secure integration of libraries, we developed NODESENTRY, the first security architecture for server-side JavaScript. Our policy enforcement infrastructure supports an easy deployment of web hardening techniques and access control policies on interactions between libraries and their environment, including any dependent library. We discuss the design and implementation of NODESENTRY and present its performance and security evaluation.

Free and Open Source Software (FOSS) components are ubiquitous in both proprietary and open source applications. Each time a vulnerability is disclosed in a FOSS component, a software vendor using this component in an application must decide whether to update the FOSS component, patch the application itself, or just do nothing as the vulnerability is not applicable to the older version of the FOSS component used. This is particularly challenging for enterprise software vendors that consume thousands of FOSS components and offer more than a decade of support and security fixes for their applications. Moreover, customers expect vendors to react quickly on disclosed vulnerabilities-in case of widely discussed vulnerabilities such as Heartbleed, within hours. To address this challenge, we propose a screening test: a novel, automatic method based on thin slicing, for estimating quickly whether a given vulnerability is present in a consumed FOSS component by looking across its entire repository. We show that our screening test scales to large open source projects (e.g., Apache Tomcat, Spring Framework, Jenkins) that are routinely used by large software vendors, scanning thousands of commits and hundred thousands lines of code in a matter of minutes. Further, we provide insights on the empirical probability that, on the above mentioned projects, a potentially vulnerable component might not actually be vulnerable after all.

Background: Vulnerable dependencies are a known problem in today's open-source software ecosystems because OSS libraries are highly interconnected and developers do not always update their dependencies.

Context: Tabular and graphical representations are used to communicate security risk assessments for IT systems. However, there is no consensus on which type of representation better supports the comprehension of risks (such as the relationships between threats, vulnerabilities and security controls). Vessey's cognitive fit theory predicts that graphs should be better because they capture spatial relationships. Method: We report the results of two studies performed in two countries with 69 and 83 participants respectively, in which we assessed the effectiveness of tabular and graphical representations concerning the extraction of correct information about security risks. Results: Participants who applied tabular risk models gave more precise and complete answers to the comprehension questions when requested to find simple and complex information about threats, vulnerabilities, or other elements of the risk models. Conclusions: Our findings can be explained by Vessey's cognitive fit theory as tabular models implicitly capture elementary linear spatial relationships. Interest for ICSE: It is almost taken for granted in Software Engineering that graphical-, diagram-based models are "the" way to go (e.g., the SE Body of Knowledge [3]). This paper provides some experimental-based doubts that this might not always be the case. It will provide an interesting debate that might ripple to traditional requirements and design notations outside security.

In a Futures-Exchange, such as the Chicago Mercantile Exchange, traders buy and sell contractual promises (futures) to acquire or deliver, at some future pre-specified date, assets ranging from wheat to crude oil and from bacon to cash in a desired currency. The interactions between economic and security properties and the exchange's essentially non-monotonic security behavior; a valid trader's valid action can invalidate other traders' previously valid positions, are a challenge for security research. We show the security properties that guarantee an Exchange's economic viability (availability of trading information, liquidity, confidentiality of positions, absence of price discrimination, risk-management) and an attack when traders' anonymity is broken. We describe all key operations for a secure, fully distributed Futures-Exchange, hereafter referred to as simply the 'Exchange'. Our distributed, asynchronous protocol simulates the centralized functionality under the assumptions of anonymity of the physical layer and availability of a distributed ledger. We consider security with abort (in absence of honest majority) and extend it to penalties. Our proof of concept implementation and its optimization (based on zk-SNARKs and SPDZ) demonstrate that the computation of actual trading days (along Thomson-Reuters Tick History DB) is feasible for low-frequency markets; however, more research is needed for high-frequency ones.

Vulnerability exploitation is reportedly one of the main attack vectors against computer systems. Yet, most vulnerabilities remain unexploited by attackers. It is therefore of central importance to identify vulnerabilities that carry a high 'potential for attack'. In this paper we rely on Symantec data on real attacks detected in the wild to identify a trade-off in the Impact and Complexity of a vulnerability in terms of attacks that it generates; exploiting this effect, we devise a readily computable estimator of the vulnerability's Attack Potential that reliably estimates the expected volume of attacks against the vulnerability. We evaluate our estimator performance against standard patching policies by measuring foiled attacks and demanded workload expressed as the number of vulnerabilities entailed to patch. We show that our estimator significantly improves over standard patching policies by ruling out low-risk vulnerabilities, while maintaining invariant levels of coverage against attacks in the wild. Our estimator can be used as a first aid for vulnerability prioritisation to focus assessment efforts on high-potential vulnerabilities.

[Background] Security risk assessment methods in industry mostly use a tabular notation to represent the assessment results whilst academic works advocate graphical methods. Experiments with MSc students showed that the tabular notation is better than an iconic graphical notation for the comprehension of security risks. [Aim] We investigate whether the availability of textual labels and terse UML-style notation could improve comprehensibility. [Method] We report the results of an online comprehensibility experiment involving 61 professionals with an average of 9 years of working experience, in which we compared the ability to comprehend security risk assessments represented in tabular, UML-style with textual labels, and iconic graphical modeling notations. [Results] Tabular notation are still the most comprehensible notion in both recall and precision. However, the presence of textual labels does improve the precision and recall of participants over iconic graphical models. [Conclusion] Tabular representation better supports extraction of correct information of both simple and complex comprehensibility questions about security risks than the graphical notation but textual labels help.

Background: Static analysis security testing (SAST) tools may be evaluated using synthetic micro benchmarks and benchmarks based on real-world software. Aims: The aim of this study is to address the limitations of the existing SAST tool benchmarks: lack of vulnerability realism, uncertain ground truth, and large amount of findings not related to analyzed vulnerability. Method: We propose Delta-Bench - a novel approach for the automatic construction of benchmarks for SAST tools based on differencing vulnerable and fixed versions in Free and Open Source (FOSS) repositories. To test our approach, we used 7 state of the art SAST tools against 70 revisions of four major versions of Apache Tomcat spanning 62 distinct Common Vulnerabilities and Exposures (CVE) fixes and vulnerable files totalling over 100K lines of code as the source of ground truth vulnerabilities. Results: Our experiment allows us to draw interesting conclusions (e.g., tools perform differently due to the selected benchmark). Conclusions: Delta-Bench allows SAST tools to be automatically evaluated on the real-world historical vulnerabilities using only the findings that a tool produced for the analysed vulnerability.

Many state-of-art mobile application testing frameworks (e.g., Dynodroid [1], EvoDroid [2]) enjoy Emma [3] or other code coverage libraries to measure the coverage achieved. The underlying assumption for these frameworks is availability of the app source code. Yet, application markets and security researchers face the need to test third-party mobile applications in the absence of the source code. There exists a number of frameworks both for manual and automated test generation that address this challenge. However, these frameworks often do not provide any statistics on the code coverage achieved, or provide coarse-grained ones like a number of activities or methods covered. At the same time, given two test reports generated by different frameworks, there is no way to understand which one achieved better coverage if the reported metrics were different (or no coverage results were provided). To address these issues we designed a framework called BBOXTESTER that is able to generate code coverage reports and produce uniform coverage metrics in testing without the source code. Security researchers can automatically execute applications exploiting current state-of-art tools, and use the results of our framework to assess if the security-critical code was covered by the tests. In this paper we report on design and implementation of BBOXTESTER and assess its efficiency and effectiveness.

Static analysis of Android applications can be hindered by the presence of the popular dynamic code update techniques: dynamic class loading and reflection. Recent Android malware samples do actually use these mechanisms to conceal their malicious behavior from static analyzers. These techniques defuse even the most recent static analyzers that usually operate under the "closed world" assumption (the targets of reflective calls can be resolved at analysis time; only classes reachable from the class path at analysis time are used at runtime). Our proposed solution allows existing static analyzers to remove this assumption. This is achieved by combining static and dynamic analysis of applications in order to reveal the hidden/updated behavior and extend static analysis results with this information. This paper presents design, implementation and preliminary evaluation results of our solution called StaDynA.

Security enforcement mechanisms like execution monitors are used to make sure that some untrusted program complies with a policy. Different enforcement mechanisms have different strengths and weaknesses and hence it is important to understand the qualities of various enforcement mechanisms.

Evaluation and validation methodologies are integral parts of Air Traffic Management (ATM). They are well understood for safety, environment and other Key Performance Areas, for which operational validation guidelines are well defined and widely used. In contrast, the effectiveness of risk assessment methods and practices for security, as well as their comparative evaluation is largely uncharted territory. There is limited information about the degree the practices and their corresponding activities provide security and whether or not they give return on investment. The "Empirical Framework for Security Design and Economics Trade-off" (EMFASE) project is investigating the above questions by applying different risk assessment methods on different application scenarios, such as the Remotely Operated Tower, and by evaluating them with respect to their performance, security impact, usability, and economy. In this paper we report the preliminary work carried out in EMFASE about the elicitation of a set of ATM relevant evaluation criteria for the comparison and assessment of the risk assessment methods under study and a brief description of the first set of experiments carried out.

While careful and prudent settings for airport security policies and strategies are more important than ever, most of them have been implemented as a direct result of terrorist activities rather than motivated by a proper assessment. Furthermore, even if many scholars have proposed ways to assess and evaluate alternative airport security policies particularly by using cost-benefit analysis, they have overlooked two important facets: parameter measurability and social aspects of security policies. In this study, we develop a variant of cost-benefit analysis which we term "Relative Cost-Benefit Analysis" and illustrate how we can resolve these problems.

Node.js is a popular JavaScript server-side framework with an efficient runtime for cloud-based event-driven architectures. Its strength is the presence of thousands of third-party libraries which allow developers to quickly build and deploy applications. These very libraries are a source of security threats as a vulnerability in one library can (and in some cases did) compromise one's entire server.

Context: Poste Italiane is a large corporation offering integrated services in banking and savings, postal services, and mobile communication. Every year, it receives thousands of change requests for its ICT services. Applying to each and every request a security assessment "by the book" is simply not possible. Goal: We report the experience by Poste Italiane of a lean methodology to identify security requirements that can be inserted in the production cycle of a normal company. Method: The process is based on surveying the overall IT architectures (Security Survey) and then a lean dynamic process (Security Triage) to evaluate individual change requests, so that important changes get the attention they need, minor changes can be quickly implemented, and compliance and security obligations are met. Results: The empirical evaluation conducted for over an year at Poste Italiane shows that the process significantly reduces the time to identify security requirements at the pace of change. Conclusions: The Security Survey and Triage process should thus be embedded in a company's production cycle as mandatory step to manage change requests so that security initiatives are prioritized based on the relevance of the assets and of the business objectives of the company.

Software systems could be seen as a hierarchy of features which are evolving due to the dynamic of the working environments. The companies who build software thus need to make an appropriate strategy, which takes into consideration of such dynamic, to select features to be implemented. In this work, we propose an approach to facilitate such selection by providing a means to capture the uncertainty of evolution in feature models. We also provide two analyses to support the decision makers. The approach is exemplified in the Smart Grid scenario.

(U.S.) Rule-based policies for mitigating software risk suggest using the CVSS score to measure the risk of an individual vulnerability and act accordingly. A key issue is whether the ‘danger’ score does actually match the risk of exploitation in the wild, and if and how such a score could be improved. To address this question, we propose using a case-control study methodology similar to the procedure used to link lung cancer and smoking in the 1950s. A case-control study allows the researcher to draw conclusions on the relation between some risk factor (e.g., smoking) and an effect (e.g., cancer) by looking backward at the cases (e.g., patients) and comparing them with controls (e.g., randomly selected patients with similar characteristics). The methodology allows us to quantify the risk reduction achievable by acting on the risk factor. We illustrate the methodology by using publicly available data on vulnerabilities, exploits, and exploits in the wild to (1) evaluate the performances of the current risk factor in the industry, the CVSS base score; (2) determine whether it can be improved by considering additional factors such the existence of a proof-of-concept exploit, or of an exploit in the black markets. Our analysis reveals that (a) fixing a vulnerability just because it was assigned a high CVSS score is equivalent to randomly picking vulnerabilities to fix; (b) the existence of proof-of-concept exploits is a significantly better risk factor; (c) fixing in response to exploit presence in black markets yields the largest risk reduction.

Vulnerability discovery models (VDMs) operate on known vulnerability data to estimate the total number of vulnerabilities that will be reported after a software is released. VDMs have been proposed by industry and academia, but there has been no systematic independent evaluation by researchers who are not model proponents. Moreover, the traditional evaluation methodology has some issues that biased previous studies in the field. In this work we propose an empirical methodology that systematically evaluates the performance of VDMs along two dimensions (quality and predictability) and addresses all identified issues of the traditional methodology. We conduct an experiment to evaluate most existing VDMs on popular web browsers' vulnerability data. Our comparison shows that the results obtained by the proposed methodology are more informative than those by the traditional methodology. Among evaluated VDMs, the simplest linear model is the most appropriate choice in terms of both quality and predictability for the first 6-12 months since a release date. Otherwise, logistics-based models are better choices.

While many governments and airport operators have emphasized the importance of security training and committed a large amount of budget to security training programs, the implementation of security training programs was not proactive but reactive. Moreover, most of the security training programs were employed as a demand or a trend-chasing activity from the government. In order to identify issues in airport security training and to develop desirable security training procedures in an airport, this preliminary study aims at providing (1) the description of current state of airport security training and training in general, (2) the study design and interview guide for studying airport security training, and (3) expected outcome from the study.

NVD is one of the most popular databases used by researchers to conduct empirical research on data sets of vulnerabilities. Our recent analysis on Chrome vulnerability data reported by NVD has revealed an abnormally phenomenon in the data where almost vulnerabilities were originated from the first versions. This inspires our experiment to validate the reliability of the NVD vulnerable version data. In this experiment, we verify for each version of Chrome that NVD claims vulnerable is actually vulnerable. The experiment revealed several errors in the vulnerability data of Chrome. Furthermore, we have also analyzed how these errors might impact the conclusions of an empirical study on foundational vulnerability. Our results show that different conclusions could be obtained due to the data errors.

A significant number of methods have been proposed to identify and analyze threats and security requirements, but there are few empirical evaluations that show these methods work in practice. This paper reports a controlled experiment conducted with 28 master students to compare two classes of risk-based methods, visual methods (CORAS) and textual methods (SREP). The aim of the experiment was to compare the effectiveness and perception of the two methods. The participants divided in groups solved four different tasks by applying the two methods using a randomized block design. The dependent variables were effectiveness of the methods measured as number of threats and security requirements identified, and perception of the methods measured through a post-task questionnaire based on the Technology Acceptance Model. The experiment was complemented with participants' interviews to determine which features of the methods influence their effectiveness. The main findings were that the visual method is more effective for identifying threats than the textual one, while the textual method is slightly more effective for eliciting security requirements. In addition, visual method overall perception and intention to use were higher than for the textual method.

The vulnerability discovery process normally refers to the post-release stage where people identify and report security flaws of a released software. Vulnerability discovery models (VDM) operate on the known vulnerability data to estimate the total number of vulnerabilities present in the software. Successful models can be useful hints for both software vendors and users in allocating resources to handle potential breaches, and tentative patch update. For example, we do not exactly know the day of major snow falls but cities expect it to fall in winter and therefore plan resources for road clearing in that period. The effective planning is important because security bugs are different than "normal" bugs. A normal bugs might be filed and be scheduled for fixing in the next release. Meanwhile a security vulnerability might required an urgent patch to be shipped to customers lest their browser be subject to rogue campaigns. Major shifts in browser usage are often attributed to (real or perceived) "more" security. Understanding the security trend is therefore important.

Change management and change propagation across the various models of the system (such as requirements, design and testing models) are well-known problems in software engineering. For such problems a number of solutions have been proposed that are usually based on the integration of model repositories and on the maintenance of traceability links between the models. We propose to manage the mutual evolution of requirements models and tests models by orchestrating processes based on a minimal shared interface. Thus, requirement and test engineers must only have a basic knowledge about the ``other'' domain, share a minimal set of concepts and can follow their ``own'' respective processes. The processes are orchestrated in the sense that when a change affects a concept of the interface, the change is propagated to the other domain. We illustrate the approach using the evolution of the Global Platform standard.

Runtime enforcement is a common mechanism for ensuring that program executions adhere to constraints specified by a security policy. It is based on two simple ideas: the enforcement mechanism should leave good executions without changes (transparency) and make sure that the bad ones got amended (so undness). From the theory side, a number of papers (Hamlen et al., Ligatti et al., Talhi et al.) provide the precise characterization of good executions that can be captured by a security policy and thus enforced by mechanisms like security automata or edit automata. Unfortunately, transparency and soundness do not distinguish what happens when an execution is actually bad (the practical case). They only tell that the outcome of enforcement mechanism should be “good” but not how far the bad execution should be changed. So we cannot formally distinguish between an enforcement mechanism that makes a small change and one that drops the whole execution. In this paper we explore a set of policies called iterative properties that revises the notion of good executions in terms of repeated iterations. We propose an enforcement mechanism that can deal with bad executions (and not only the good ones) in a more predictable way by eliminating bad iterations.

Managing changes in Security Engineering is a difficult task: the analyst must keep the consistency between security knowledge such as assets, attacks and treatments to stakeholders' goals and security requirements. Research-wise the usual solution is an integrated methodology in which risk, security requirements and architectural solutions are addressed within the same tooling environment and changes can be easily propagated. This solution cannot work in practice as the steps of security engineering process requires to use artefacts (documents, models, data bases) and manipulate tools that are disjoint and cannot be fully integrated for a variety of reasons (separate engineering domains, outsourcing, confidentiality, etc.). We call such processes legacy security engineering processes. In this paper, we propose a change management framework for legacy security engineering processes. The key idea is to separate concerns between the requirements, risk and architectural domains while keeping an orchestrated view (as opposed to an integrated view). We identify some mapping concepts among the domains so that little knowledge is required from the requirement manager about the other domains, and similarly for security risk manager and the system designer: they can stick to their well known (and possibly certified) internal process. This minimal set of concepts is the interface between the legacy processes. The processes are then orchestrated in the sense that when a change affects a concept of the interface, the change is propagated to the other domain. We illustrate this example by using the risk modeling language (Security DSML) from Thales Research and the security requirement language (SI*) from the Univ. of Trento.

We investigate non-interference (secure information flow) policies for web browsers, replacing or complementing the Same Origin Policy. First, we adapt a recently proposed dynamic information flow enforcement mechanism to support asynchronous I/O. We prove detailed security and precision results for this enforcement mechanism, and implement it for the Featherweight Firefox browser model. Second, we investigate three useful web browser security policies that can be enforced by our mechanism, and demonstrate their value and limitations.

Security-by-Contract (S×C) is a paradigm providing security assurances for mobile applications. In this work, we present an extension of S×C enriched with an automatic trust management infrastructure. Indeed, we enhance the already existing architecture by adding new modules and configurations for contracts managing. At deploy-time, our system decides the run-time configuration depending on the credentials of contract provider. Roughly, the run-time environment can both enforce a security policy and monitor the declared contract. According to the actual behaviour of the running program our architecture updates the trust level associated with the contract provider. The main advantage of this method is an automatic management of the level of trust of software and contract releasers.

Security and trust are core research issues for the further development of the Information Society and for 10 years have played, and continue to play, an integral part in the European Union’s Framework Programmes (FPs) for R&D. EU-supported collaborative research projects in trust and security bring together multi-partner stakeholders from industry (technology and service providers, system integrators and end-users), academic and research laboratories working in several interdisciplinary research fields. Sometimes, projects include actors from the legal, social and economic sectors. Together their joint efforts permit a better understanding of the conflicts and synergies between security, privacy and free market economics, as well as of the psychology and sociology of trust and security when building and deploying new technologies. The long term goal for funding this research effort is to convert the know-how of the EU in security, privacy and trust into economic advantages. In the period 1998–2002, under FP5, original and ground-breaking scientific & technological (S&T) work took place in ICT Trust and Security. Key S&T developments achieved at that period included significant advances in cryptology, smart cards and biometrics. EU-supported research also permitted the identification of new concepts in fields of work such as privacy, dependability and risk analysis. In the period 2002–2006, under FP6, research efforts in ICT security and trust have been further intensified. As part of the FP6-IST Programme, 37 R&D projects

Management of a modern enterprise is based on the assumption that executive reports of lower-layer management are faithful to what is actually happening in the field. As some well-publicised major recent disasters (such as Barings, AllFirst-Allied Irish Bank, ENRON, Societé Generale) have shown, this assumption is not well-founded. Intermediate managers can misrepresent the actual state of their systems in order to hide negative events or to "doctor" reports which have been already produced. Existing security approaches which guarantee integrity of logs and related reports do not protect the system against these threats, if they are directly applied to a multi-layered corporate structure. In this paper, we extend existing approaches by constructing a logging scheme which ensures that, at each level, logs are both correct and consistent.

In our own previous work [1], we looked at the problem of designing IT solutions ( Security Patterns) accounting for legal and organizational issues. The proposed pattern de- sign and validation process require legal experts to describe patterns in natural language. Such a description is parsed by a natural language processor on the basis of a semantic template [2]. The annotated description is then used to automatically generate graphical models of SI* patterns, which are revised by security engineers using a CASE Tool 1. The intriguing question that we address in this paper is the opposite of the mainstream one: Challenge 1. You have a technical solution (e.g. a se- curity and dependability pattern). Can some of your system requirements be implemented by legal means? This challenge might seem at odd with intuition but only because we don't bring the usage of patterns to their logi- cal end: if an answer to a legal, organizational or technical security requirement can be an organizati...

There is increasing demand for running interacting applications in a secure and controllable way on mobile devices. Such demand is not fully supported by the Java/.NET security model based on trust domains nor by current security monitors or language-based security approaches. We propose an approach that allows security policies that are i) expressive enough to capture multiple sessions and interacting applications, ii) suitable for efficient monitoring, iii) convenient for a developer to specify them. Since getting all three at once is impossible, we advocate a logical language, 2D-LTL a bi-dimensional temporal logic fit for multiple sessions and for which efficient monitoring algorithms can be given, and a graphical language based on standard UML sequence diagrams with a tight correspondence between the two.

Autonomic communication and computing is a new paradigm for dynamic service integration over a network. An autonomic network crosses organizational and management boundaries and is provided by entities that see each other just as partners. For many services no autonomic partner may guess a priori what will be sent by clients nor clients know a priori what credentials are required to access a service. To address this problem we propose a new interactive access control : servers should interact with clients, asking for missing credentials necessary to grant access, whereas clients may supply or decline the requested credentials. Servers evaluate their policies and interact with clients until a decision of grant or deny is taken. This proposal is grounded in a formal model on policy-based access control. It identifies the formal reasoning services of deduction, abduction and consistency. Based on them, the work proposes a comprehensive access control framework for autonomic systems. An implementation of the interactive model is given followed by system performance evaluation.

The importance of critical systems has been widely recognized and several efforts are devoted to integrate dependability requirements in their development process. Such efforts result in a number of models, frameworks, and methodologies that have been proposed to model and assess the dependability of critical systems. Among them, risk analysis considers the likelihood and severity of failures for evaluating the risk affecting the system. In our previous work, we introduced the Tropos goal-risk framework, a formal framework for modeling, assessing, and treating risks on the basis of the likelihood and severity of failures. In this paper, we refine this framework introducing the notion of trust for assessing risks on the basis of the organizational setting of the system. The assessment process is also enhanced to analyze risks along trust relations among actors. To make the discussion more concrete, we illustrate the framework with a case study on partial airspace delegation in air traffic management system

There is a large number of research papers and standards dedicated to security for outsourced data. Yet, most papers propose new controls to access and protect the data rather than to assess the level of assurance of the whole process that is currently deployed. The main contributions of the paper is an approach for aggregating security properties of individual tasks of a complex business process in order to receive the level of assurance provided by the whole process. The approach takes into account the fact that some tasks of a business process may be outsourced and thus account for not very reliable partners. The approach chooses the concrete business process offering the highest assurance among several possible design alternatives by building an optimal hyper-path traversing the business process.

Laws set requirements that force organizations to assess the security and privacy of their IT systems and impose the adoption of the implementation of minimal precautionary security measures. Several frameworks have been proposed to deal with thii issue. For instance, purpose-based access control is normally considered a good solution for meeting the requirements of privacy legislation. Yet, understanding why, how, and when such solutions to security and privacy problems have to be deployed is often unanswered.

Privacy protection is a growing concern in the marketplace. Yet, privacy requirements and mechanisms are usually retro-fitted into a pre-existing design which may not be able to accommodate them due to potential conflicts with functional requirements. We propose a procedure for automatically extracting privacy requirements from databases supporting access control mechanisms for personal data (hereafter Hippocratic databases) and representing them in the Secure Tropos framework where tools are available for checking the correctness and consistency of privacy requirements. The procedure is illustrated with a case study.

System vulnerabilities are often caused by the presence of conflicts within the organization where the system-to-be would eventually operate. In particular, conflicts of interest are very harmful since actors can exploit their positions/roles relative to the system for gaining personal advantage. Capturing and resolving such conflicts is a necessary condition for developing secure information systems. In this paper, we show how conflicts of interest can be formally detected during requirements analysis. This allows system designers to investigate the causes for which conflicts may occur in an organization. Thereby, they can better understand the organizational structure and so provide appropriate countermeasures to resolve or at least mitigate them

Autonomic communications seek to improve the ability of network and services to cope with unpredicted change, including changes in topology, load, task, the physical and logical characteristics of the networks that can be accessed, and so forth. Broad-ranging autonomic solutions require designers to account for a range of end-to-end issues affecting programming models, network and contextual modeling and reasoning, decentralised algorithms, trust acquisition and maintenance---issues whose solutions may draw on approaches and results from a surprisingly broad range of disciplines. We survey the current state of autonomic communications research and identify significant emerging trends and techniques.

Security requirements engineering is emerging as a branch of software engineering, spurred by the realization that security must be dealt with early on during the requirements phase. Methodologies in this field are challenging, as they must take into account subtle notions such as trust (or lack thereof), delegation, and permission; they must also model entire organizations and not only systems-to-be. In our previous work we introduced Secure Tropos, a formal framework for modeling and analyzing security requirements. Secure Tropos is founded on three main notions: ownership, trust, and delegation. In this paper, we refine Secure Tropos introducing the notions of at-least delegation and trust of execution; also, at-most delegation and trust of permission. We also propose monitoring as a security design pattern intended to overcome the problem of lack of trust between actors. The paper presents a semantic for these notions, and describes an implemented formal reasoning tool based on Datalog.

Security requirements engineering is emerging as a branch of software engineering, spurred by the realization that security must be dealt with early on during the requirements phase. We propose ST-tool, a CASE tool developed for modeling and analyzing functional and security requirements.

We investigate a generalization of the notion of XML security view introduced by Stoica and Farkas [17] and later refined by Fan et al. [8]. The model consists of access control policies specified over DTDs with XPath expression for data-dependent access control policies. We provide the notion of security views for characterizing information accessible to authorized users. This is a transformed (sanitized) DTD schema that can be used by users for query formulation and optimization. Then we show an algorithm to materialize "authorized" version of the document from the view and an algorithm to construct the view from an access control specification. We also propose a number of generalizations for security policies.

Secure electronic transaction (SET) is an immense e-commerce protocol designed to improve the security of credit card purchases. In this paper, we focus on the initial bootstrapping phases of SET, whose objective is the registration of cardholders and merchants with a SET certificate authority. The aim of registration is twofold: getting the approval of the cardholder's or merchant's bank and replacing traditional credit card numbers with electronic credentials that cardholders can present to the merchant so that their privacy is protected. These registration subprotocols present a number of challenges to current formal verification methods. First, they do not assume that each agent knows the public keys of the other agents. Key distribution is one of the protocols' tasks. Second, SET uses complex encryption primitives (digital envelopes) which introduce dependency chains: the loss of one secret key can lead to potentially unlimited losses. Building upon our previous work, we have been able to model and formally verify SETs registration with the inductive method in Isabelle/HOL (T. Nipkow et al., 2002). We have solved its challenges with very general techniques.

The Secure Electronic Transaction (SET) protocol has been proposed by a consortium of credit card companies and software corporations to secure e-commerce transactions. When the customer makes a purchase, the SET dual signature guarantees authenticity while keeping the customer's account details secret from the merchant and his choice of goods secret from the bank.This paper reports the first verification results for the complete purchase phase of SET. Using Isabelle and the inductive method, we showed that the credit card details do remain confidential and customer, merchant and bank can confirm most details of a transaction even when some of those details are kept from them. The complex protocol construction makes proofs more difficult but still feasible.Though enough goals can be proved to give confidence in SET, a lack of explicitness in the dual signature makes some agreement properties fail: it is impossible to prove that the customer meant to sent his credit card details to the payment gateway that receives them.

We illustrate AL SP (Action Language for Security Protocol), a declarative executable specification language for planning attacks to security protocols. AL SP is based on logic programming with negation as failure, and with stable model semantics. In AL SP we can give a declarative specification of a protocol with the natural semantics of send and receive actions which can be performed in parallel. By viewing a protocol trace as a plan to achieve a goal, attacks are (possibly parallel) plans achieving goals that correspond to security violations. Building on results from logic programming and planning, we map the existence of an attack into the existence of a model for the protocol that satisfies the specification of an attack. We show that our liberal model of parallel actions can adequately represent the traditional Dolev-Yao trace-based model used in the formal analysis of security protocols. Specifications in AL SP are executable, as we can automatically search for attacks via an efficient model generator (smodels), implementing the stable model semantics of normal logic programs.

We propose AL/sub SP/ a Declarative Executable Specification Language for Planning Attacks to Security Protocols based on logic programming. In AL/sub SP/ we can give a declarative specification of a protocol with the natural semantics of send and receive actions. We view a protocol trace as a plan to reach a goal, so that attacks are just plans reaching goals that correspond to security violations, which can be also declaratively specified. Building on results from logic programming and planning, we map the existence of an attack to a protocol into the existence of a model for the protocol specification that satisfies the specification of an attack. AL/sub SP/ specifications are executable, as we can automatically search for attacks via any efficient model generator (such as smodels), that implements the stable model semantics of normal logic programs. Thus, we come to a specification language which is easy to use (protocol specifications are expressed at a high level of abstraction, and with an intuitive notation close to their traditional description) still keeping the rigor of a formal specification that, in addition, is executable.

Formal verification is a key step in the development of trusted and reliable multi-agent distributed systems. This is particularly relevant when security concerns such as privacy, integrity and availability impose limitations on the operations that can be performed on sensitive data. The aim of access control is to limit what agents (humans, programs, softbots, etc.) of distributed systems can do directly or indirectly by delegating their powers and tasks. As the size of the systems and the sensitivity of data increase, the availability of automated reasoning methods becomes essential for logical analysis of access control. This paper presents a prefixed tableau method for the calculus of access control developed at the Digital System Research Center. This calculus is particularly interesting for a number of reasons. First it was the basis for the development and the verification of an implemented system. Second, it poses many technical challenges for classical modal tableaux: it lacks the tree-model property, has some features of the universal modality, and can introduce delegation certificates between agents “on-the-fly” not compilable into axiom schemata.

Contextual reasoning has been proposed as a tool for solving the problem of generality in AI and for effectively handling huge knowledge bases, while approximate reasoning has been developed to overcome the computational barrier of classical deduction. This paper combines these approaches to provide an intuitive representation of knowledge and an effective deduction. Its semantics and a tableau calculus are presented. The key computational features are discussed.