Time for Addressing Software Security Issues: Prediction Models and Impacting Factors

Finding and fixing software vulnerabilities have become a major struggle for most software development companies. While generally without alternative, such fixing efforts are a major cost factor, which is why companies have a vital interest in focusing their secure software development activities such that they obtain an optimal return on this investment. We investigate, in this paper, quantitatively the major factors that impact the time it takes to fix a given security issue based on data collected automatically within SAP’s secure development process, and we show how the issue fix time could be used to monitor the fixing process. We use three machine learning methods and evaluate their predictive power in predicting the time to fix issues. Interestingly, the models indicate that vulnerability type has less dominant impact on issue fix time than previously believed. The time it takes to fix an issue instead seems much more related to the component in which the potential vulnerability resides, the project related to the issue, the development groups that address the issue, and the closeness of the software release date. This indicates that the software structure, the fixing processes, and the development groups are the dominant factors that impact the time spent to address security issues. SAP can use the models to implement a continuous improvement of its secure software development process and to measure the impact of individual improvements. The development teams at SAP develop different types of software, adopt different internal development processes, use different programming languages and platforms, and are located in different cities and countries. Other organizations, may use the results—with precaution—and be learning organizations

On the Security Cost of Using a Free and Open Source Component in a Proprietary Product

The work presented in this paper is motivated by the need to estimate the security effort of consuming Free and Open Source Software (FOSS) components within a proprietary software supply chain of a large European software vendor. To this extent we have identified three different cost models: centralized (the company checks each component and propagates changes to the different product groups), distributed (each product group is in charge of evaluating and fixing its consumed FOSS components), and hybrid (only the least used components are checked individually by each development team). We investigated publicly available factors (\eg, development activity such as commits, code size, or fraction of code size in different programming languages) to identify which one has the major impact on the security effort of using a FOSS component in a larger software product

Security assessment of open source third-parties applications

Free and Open Source Software (FOSS) components are ubiquitous in both proprietary and open source applications. In this dissertation we discuss challenges that large software vendors face when they must integrate and maintain FOSS components into their software supply chain. Each time a vulnerability is disclosed in a FOSS component, a software vendor must decide whether to update the component, patch the application itself, or just do nothing as the vulnerability is not applicable to the deployed version that may be old enough to be not vulnerable. 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 applications that include these components. First, we design a framework for performing security vulnerability experimentations. In particular, for testing known exploits for publicly disclosed vulnerabilities against different versions and software configurations. Second, we provide an automatic screening test for quickly identifying the versions of FOSS components likely affected by newly disclosed vulnerabilities: a novel method that scans across the entire repository of a FOSS component in a matter of minutes. We show that our screening test scales to large open source projects. Finally, for facilitating the global security maintenance of a large portfolio of FOSS components, we discuss various characteristics of FOSS components and their potential impact on the security maintenance effort, and empirically identify the key drivers

Evaluating Information Assurance Control Effectiveness on an Air Force Supervisory Control and Data Acquisition (SCADA) System

Supervisory Control and Data Acquisition (SCADA) systems are increasingly being connected to corporate networks which has dramatically expanded their attack surface to remote cyber attack. Adversaries are targeting these systems with increasing frequency and sophistication. This thesis seeks to answer the research question addressing which Information Assurance (IA) controls are most significant for network defenders and SCADA system managers/operators to focus on in order to increase the security of critical infrastructure systems against a Stuxnet-like cyber attack. This research applies the National Institute of Science and Technology (NIST) IA controls to an attack tree modeled on a remote Stuxnet-like cyber attack against the WPAFB fuels operation. The probability of adversary success of specific attack scenarios is developed via the attack tree. Then an impact assessment is obtained via a survey of WPAFB fuels operation subject matter experts (SMEs). The probabilities of adversary success and impact analysis are used to create a Risk Level matrix, which is analyzed to identify recommended IA controls. The culmination of this research identified 14 IA controls associated with mitigating an adversary from gaining remote access and deploying an exploit as the most influential for SCADA managers, operators and network defenders to focus on in order to maximize system security against a Stuxnet-like remote cyber attack

Security Patch Management - An Overview of the Patching Process and its Challenges in Norwegian Businesses

Cyber-attacks are growing more frequent and sophisticated, and they are impacting businesses of all sizes. This encourages businesses to utilize safe, flaw-free systems, making them less susceptible to cyber-attacks. The issue is that no system is flawless, and a substantial number of security flaws are discovered regularly. To ensure the system's security, patches are distributed and implemented. Patches can be complicated and implementing them in systems can be difficult. This thesis seeks to identify the challenges that make the patching process challenging and to propose potential solutions. This thesis was conducted utilizing a qualitative research strategy and methods such as a systematic literature review, to identify existing patching challenges identified by previous research. We conducted interviews with business professionals who were familiar with the patching procedure and had understanding of cybersecurity. The majority of our interviewees were managers with additional expertise leading patching teams. Prior study indicated various challenges in the field of patching and urged further investigation into the issue of patching. Our findings correlated with the current challenges identified by prior research, and we uncovered important new challenges, such as the fact that patches for major vulnerabilities have a tendency to be released just before a holiday, and that legacy systems are notoriously difficult to patch and are sometimes not patched at all. The significance of planning, organization, and communication in the patching process posed additional challenges. The contribution of this thesis to the patching topic is that we have identified "Planned patch delay" as a patch policy that contributes to a high security posture, provides time for patch planning, and mitigates a number of the challenges that might arise during the patching process. Keywords: Patch, Security patching, Patch challenges, Patch legacy, Patch meetings, Patch policy, Patch prioritization, Patch proces

Security Patch Management - An Overview of the Patching Process and its Challenges in Norwegian Businesses

Cyber-attacks are growing more frequent and sophisticated, and they are impacting businesses of all sizes. This encourages businesses to utilize safe, flaw-free systems, making them less susceptible to cyber-attacks. The issue is that no system is flawless, and a substantial number of security flaws are discovered regularly. To ensure the system's security, patches are distributed and implemented. Patches can be complicated and implementing them in systems can be difficult. This thesis seeks to identify the challenges that make the patching process challenging and to propose potential solutions. This thesis was conducted utilizing a qualitative research strategy and methods such as a systematic literature review, to identify existing patching challenges identified by previous research. We conducted interviews with business professionals who were familiar with the patching procedure and had understanding of cybersecurity. The majority of our interviewees were managers with additional expertise leading patching teams. Prior study indicated various challenges in the field of patching and urged further investigation into the issue of patching. Our findings correlated with the current challenges identified by prior research, and we uncovered important new challenges, such as the fact that patches for major vulnerabilities have a tendency to be released just before a holiday, and that legacy systems are notoriously difficult to patch and are sometimes not patched at all. The significance of planning, organization, and communication in the patching process posed additional challenges. The contribution of this thesis to the patching topic is that we have identified "Planned patch delay" as a patch policy that contributes to a high security posture, provides time for patch planning, and mitigates a number of the challenges that might arise during the patching process. Keywords: Patch, Security patching, Patch challenges, Patch legacy, Patch meetings, Patch policy, Patch prioritization, Patch proces

Technical Debt Prioritization: State of the Art. A Systematic Literature Review

Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review among 384 unique papers published until 2018, following a consolidated methodology applied in Software Engineering. We included 38 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and optimizing on different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We report an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that technical Debt prioritization research is preliminary and there is no consensus on what are the important factors and how to measure them. Consequently, we cannot consider current research conclusive and in this paper, we outline different directions for necessary future investigations