Search

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.

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.

To kick-start the discussion, let's first review some of the recent attacks. In the node-ipc case1 a developer pushed an update that deliberately but stealthily included code that sabotaged the computer of the users who installed the updated component. Such an attack was selective: a DarkSide in reverse. If the computer Internet Protocol (IP) was geolocated in Russia, the attack would be launched. Several days and a few million downloads later, the spurious code was actually noticed and investigated. Linus's law on the many eyes eventually made the bug shallow,2 and the developer pulled back the changes.

This dataset contains expert assessments of the cybersecurity skills required for six job profiles in Europe, as determined via surveys responded by cybersecurity experts from academia and industry. The data can be used to identify educational needs in the cybersecurity sector and compare against other frameworks. The six cybersecurity-oriented job profiles used in the surveys are: General cybersec auditor; Technical cybersec auditor; Threat modelling engineer; Security engineer; Enterprise cybersecurity practitioner; Cybersecurity analyst. Data—i.e. expert assessments—was collected via surveys, targeted at European experts in cybersecurity from academia and industry. Respondents characterised the skills needed to perform in six job profiles using the CSEC+ framework: a cybersecurity skills framework prepared as a spreadsheet where cybersecurity skills must be ranked in a Likert scale from 0 (irrelevant) to 4 (advance knowledge needed). Metadata requested included the type of organisation of the respondent (Large company, SME, Academic/Research, Public administration, Other) and the country of origin. There were three data-collection phases: (1) an initial phase, used also to refine later larger-scale processes, carried out in Oct 2021–Jan 2022 and resulting in 13 expert assessments from four EU countries; (2) a second phase implemented as an online service broadcast to a larger audience, carried out in Mar–Apr 2022 and resulting in 15 assessments from eight European countries; (3) and a third phase, allowing direct online input and distributed in PC and mobile form, carried out in Sep–Oct 2022 and resulting in 32 assessments from ten European countries. The raw data gathered was stored and processed via spreadsheets, computing statistical information (mean, stdev) on how much each cybersecurity skill and area was deemed necessary to perform in each job profile. This is visualised as a heatmap where colour intensity symbolises value, and circle diffusion symbolises spread. Processed data further includes visualisations on how the area of origin of the respondent (academia, as in “producer of education”, vs. industry, as in “consumer of education”) influences the responses. This is shown as bar plots, where whiskers represent confidence intervals used for statistical-significance tests. This data can serve as basis to understand the educational needs for the cybersecurity sector in Europe. It can be reused for comparison against frameworks, other than CSEC+, to assess the need of education in specific cybersecurity sectors such as human security. Furthermore, the Qualtrics survey template (included) is a ready-made solution for replication studies.

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.

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.

Versed in legal, management, and cybersecurity technical skills, the data protection officer stands between those auditing a companya's compliance and those acting as management advisors. We describe how this role tackles sociotechnical risks in everyday scenarios.

We review machine learning approaches for detecting (and correcting) vulnerabilities in source code, finding that the biggest challenges ahead involve agreeing to a benchmark, increasing language and error type coverage, and using pipelines that do not flatten the code's structure.

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.

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. This version contains formal definitions, detailed security proofs, demos and experimental data in the appendix.