The use of connected medical and in vitro diagnostic devices (CMD&IVD) as part of individual care and self-care practices is growing. Significant attention is needed to ensure that CMD&IVD remain safe and secure throughout their lifecycles — as if a cybersecurity incident were to occur involving these devices, it is possible that in some cases harm may be brought to the person using them. For the effective safety management of these devices, risk assessment is needed that covers both the cybersecurity and patient safety domains. To this end, we present knowledge modelling of indirect patient harms (e.g., misdiagnosis, delayed treatment etc.) resulting from cybersecurity compromises, along with a methodology for encoding these into a previously developed automated cybersecurity risk assessment tool, to begin to bridge the gap between automated risk assessment related to cybersecurity and patient safety.

This paper describes challenges within IoT ecosystems from the perspective of cybersecurity testing along with a proposed approach to address them that will be investigated in a recently started Horizon Europe project named TELEMETRY. The key observations regarding the design of the framework are summarised as follows. There is a need to consider the full lifecycle of IoT components – at their design time, their integration into systems, and operation of those systems. Threats and risks can propagate when components are connected together in systems - vulnerabilities in one component can affect other components in a system. IoT devices present limitations to current testing and management due to geographical distribution, opacity and limited processing power. Risk assessment fulfils an important requirement because it enables assessment of what elements are important to the system’s stakeholders, how these elements may be compromised, and how the compromises may be controlled. Feedback from operational monitoring of IoT devices can inform firmware updates / patches to the devices but there is a significant challenge in rolling out these patches to multiple low-power devices geographically distributed

Critical infrastructure today is comprised of cyber-physical systems, and therefore also vulnerable to cyber threats. Many of these threats come from within, through malicious code in software updates or bugs that can be exploited. Further exacerbating the issue is the fact that most software suppliers in critical infrastructure are developing proprietary systems and giving out minimal information about the composition of their software products. With the US introduction of a Software Bill of Materials (SBOM) requirement in federal information systems, they are better prepared to deal with cyber incidents. This article examines regulations regarding software in critical infrastructure, and whether there is any benefit to mandating SBOMs in critical infrastructure.

The GRIA project set out to make the grid usable by industry. The GRIA middleware is based on Web services, and designed to meet the needs of industry for security and business-to-business (B2B) service procurement and operation. It provides well-defined B2B models for accounting and QoS agreement, and proxy-free delegation to support account management and service federation. The GRIA v3 software is now being used by industry. By taking a business-oriented approach independent of the evolving Open Grid Services Architecture proposals from the Global Grid Forum, GRIA has demonstrated the need for a wider understanding of virtual organizations (VOs). Traditional academic VOs are persistent, resourceful and have logically centralized, membership-oriented management structures. In contrast, the GRIA experience has been that business VOs are likely to be project-focused and have distributed process-oriented management structures

We introduce Grid Resources for Industrial Applications (GRIA), a project that aims to enable commercial use of the Grid. GRIA enables service providers to rent out spare CPU cycles, and clients to hire those CPU cycles. Web services play a key role in the architecture of GRIA, chiefly through their interoperability and security features - they provide a well-defined means of limiting clients' access to discrete operations, thus allowing clients to do "work" on a remote application server without giving them full shell access to the server. In this paper, we focus on requirements, business processes and security, and interoperability and standardisation issues raised by this work. We also describe some of the lessons learned through experience of designing, implementing and deploying a prototype system, GRIA vI.