Biblio

With the growing number of IoT applications and devices, IoT security breaches are a dangerous reality. Cost pressure and complexity of security tests for embedded systems and networked infrastructure are often the excuse for skipping them completely. In our paper we introduce SecLab security test lab to overcome that problem. Based on a flexible and lightweight architecture, SecLab allows developers and IoT security specialists to harden their systems with a low entry hurdle. The open architecture supports the reuse of existing external security test libraries and scalability for the assessment of complex IoT Systems. A reference implementation of security tests in a realistic IoT application scenario proves the approach.

In recent years, a variety of information security incidents emerge in endlessly, with different types. Security vulnerability is an important factor leading to the security risk of information system, and is the most common and urgent security risk in information system. The research goal of this paper is to seamlessly integrate the security testing process and the integration process of software construction, deployment, operation and maintenance. Through the management platform, the security testing results are uniformly managed and displayed in reports, and the project management system is introduced to develop, regress and manage the closed-loop security vulnerabilities. Before the security vulnerabilities cause irreparable damage to the information system, the security vulnerabilities are found and analyzed Full vulnerability, the formation of security vulnerability solutions to minimize the threat of security vulnerabilities to the information system.

Continuous Integration (CI) and Continuous Delivery (CD) have become a well-known practice in DevOps to ensure fast delivery of new features. This is achieved by automatically testing and releasing new software versions, e.g. multiple times per day. However, classical security management techniques cannot keep up with this quick Software Development Life Cycle (SDLC). Nonetheless, guaranteeing high security quality of software systems has become increasingly important. The new trend of DevSecOps aims to integrate security techniques into existing DevOps practices. Especially, the automation of security testing is an important area of research in this trend. Although plenty of literature discusses security testing and CI/CD practices, only a few deal with both topics together. Additionally, most of the existing works cover only static code analysis and neglect dynamic testing methods. In this paper, we present an approach to integrate three automated dynamic testing techniques into a CI/CD pipeline and provide an empirical analysis of the introduced overhead. We then go on to identify unique research/technology challenges the DevSecOps communities will face and propose preliminary solutions to these challenges. Our findings will enable informed decisions when employing DevSecOps practices in agile enterprise applications engineering processes and enterprise security.

Modern commercial software development organizations frequently prescribe to a development and deployment pattern for releases known as continuous integration / continuous deployment (CI/CD). Kubernetes, a cluster-based distributed application platform, is often used to implement this pattern. While the abstract concept is fairly well understood, CI/CD implementations vary widely. Resources are scattered across on-premise and cloud-based services, and systems may not be fully automated. Additionally, while a development pipeline may aim to ensure the security of the finished artifact, said artifact may not be protected from outside observers or cloud providers during execution. This paper describes a complete CI/CD pipeline running on Kubernetes that addresses four gaps in existing implementations. First, the pipeline supports strong separation-of-duties, partitioning development, security, and operations (i.e., DevSecOps) roles. Second, automation reduces the need for a human interface. Third, resources are scoped to a Kubernetes cluster for portability across environments (e.g., public cloud providers). Fourth, deployment artifacts are secured with Asylo, a development framework for trusted execution environments (TEEs).

Software is playing a pivotal role in most enterprises, whether they realize it or not, and with the proliferation of Industrial Internet of Things (IoT) and other CyberPhysical systems across our society and critical infrastructure and our collective love affair with automation, optimization, and ``smart'' devices, the role of these types of systems is only going to increase. This talk addresses the myriad of issues that underlie unsafe, insecure, and unreliable software and provides the insights of the Industrial Internet Consortium and other government and industry efforts on how to conquer them and pave the way to a marketplace of trustworthy software-enabled connected things. As the experience of several sectors has shown, the dependence on connected software needs to be met with a strong understanding of the risks to the overall trustworthiness of our software-based capabilities that we, our enterprises, and our world utilize. In many of these new connected systems issues of safety, reliability, and resilience rival or dominate concerns for security and privacy, the long-time focus of many in the IT world. Without a scalable and efficient method for managing these risks so our enterprises can continue to benefit from these advancements that powers our military, commercial industries, cities, and homes to new levels of efficiency, versatility, and cost effectiveness we face the potential for harm, death, and destructiveness. In such a marketplace, creating, exchanging, and integrating components that are trustworthy as well as entering into value-chain relationships with trustworthy partners and service suppliers will be common if we can provide a method for explicitly defining what is meant by the word trustworthy. The approach being pursued by these groups for applying Software Assurance to these systems and their Supply Chains by leveraging Structured Assurance Cases (the focus of this paper), Software Bill of Materials, and secure development practices applied to the evolving Agile and DevSecOps methodologies, is to explicitly identify the detailed requirements ``about what we need to know about something for it to be worthy of our trust'' and to do that in a way that we can convey that basis of trust to others that: can scale; is consistent within different workflows; is flexible to differing sets of hazards and environments; and is applicable to all sectors, domains, and industries.

Software is playing a pivotal role in most enterprises, whether they realize it or not, and with the proliferation of Industrial Internet of Things (IoT) and other cyber/physical systems across our society and critical infrastructure and our collective love affair with automation, optimization, and ``smart'' devices, the role of these types of systems is only going to increase. This talk addresses the myriad of issues that underlie unsafe, insecure, and unreliable software and provides the insights of the Industrial Internet Consortium and other government and industry efforts on how to conquer them and pave the way to a marketplace of trustworthy software-enabled connected things.As the experience of several sectors has shown, the dependence on connected software needs to be met with a strong understanding of the risks to the overall trustworthiness of our software-based capabilities that we, our enterprises, and our world utilize. In many of these new connected systems issues of safety, reliability, and resilience rival or dominate concerns for security and privacy, the long-time focus of many in the IT world. Without a scalable and efficient method for managing these risks so our enterprises can continue to benefit from these advancements that powers our military, commercial industries, cities, and homes to new levels of efficiency, versatility, and cost effectiveness we face the potential for harm, death, and destructiveness.In such a marketplace, creating, exchanging, and integrating components that are trustworthy as well as entering into value-chain relationships with trustworthy partners and service suppliers will be common if we can provide a method for explicitly defining what is meant by the word trustworthy. The approach being pursued by these groups for applying Software Assurance to these systems and their Supply Chains by leveraging Structured Assurance Cases, Software Bill of Materials (the focus of this paper), and secure development practices applied to the evolving Agile and DevSecOps methodologies, is to explicitly identify the detailed requirements ``about what we need to know about something for it to be worthy of our trust'' and to do that in a way that we can convey that basis of trust to others that: can scale; is consistent within different workflows; is flexible to differing sets of hazards and environments; and is applicable to all sectors, domains, and industries.

Agile and DevOps are widely adopted by the industry. Hence, integrating security activities with industrial practices, such as continuous integration (CI) pipelines, is necessary to detect security flaws and adhere to regulators’ demands early. In this paper, we analyze automated security activities in CI pipelines of enterprise-driven open source software (OSS). This shall allow us, in the long-run, to better understand the extent to which security activities are (or should be) part of automated pipelines. In particular, we mine publicly available OSS repositories and survey a sample of project maintainers to better understand the role that security activities and their related tools play in their CI pipelines. To increase transparency and allow other researchers to replicate our study (and to take different perspectives), we further disclose our research artefacts.Our results indicate that security activities in enterprise-driven OSS projects are scarce and protection coverage is rather low. Only 6.83% of the analyzed 8,243 projects apply security automation in their CI pipelines, even though maintainers consider security to be rather important. This alerts industry to keep the focus on vulnerabilities of 3rd Party software and it opens space for other improvements of practice which we outline in this manuscript.

Software applications continue to challenge user privacy when users interact with them. Privacy practices (e.g. Data Minimisation (DM), Privacy by Design (PbD) or General Data Protection Regulation (GDPR)) and related “privacy engineering” methodologies exist and provide clear instructions for developers to implement privacy into software systems they develop that preserve user privacy. However, those practices and methodologies are not yet a common practice in the software development community. There has been no previous research focused on developing “educational” interventions such as serious games to enhance software developers' coding behaviour. Therefore, this research proposes a game design framework as an educational tool for software developers to improve (secure) coding behaviour, so they can develop privacy-preserving software applications that people can use. The elements of the proposed framework were incorporated into a gaming application scenario that enhances the software developers' coding behaviour through their motivation. The proposed work not only enables the development of privacy-preserving software systems but also helping the software development community to put privacy guidelines and engineering methodologies into practice.

Practitioners use infrastructure as code (IaC) scripts to provision servers and development environments. While developing IaC scripts, practitioners may inadvertently introduce security smells. Security smells are recurring coding patterns that are indicative of security weakness and can potentially lead to security breaches. The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code (IaC) scripts through an empirical study of security smells in IaC scripts. We apply qualitative analysis on 1,726 IaC scripts to identify seven security smells. Next, we implement and validate a static analysis tool called Security Linter for Infrastructure as Code scripts (SLIC) to identify the occurrence of each smell in 15,232 IaC scripts collected from 293 open source repositories. We identify 21,201 occurrences of security smells that include 1,326 occurrences of hard-coded passwords. We submitted bug reports for 1,000 randomly-selected security smell occurrences. We obtain 212 responses to these bug reports, of which 148 occurrences were accepted by the development teams to be fixed. We observe security smells can have a long lifetime, e.g., a hard-coded secret can persist for as long as 98 months, with a median lifetime of 20 months.