cyber-resilience

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

bbossola, , Leave a comment

Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.

CVE-2022-22963

Vulnerability Score: 9.5 (CVSS: 3.0 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework.cloud:spring-cloud-function-core, org.springframework.cloud:spring-cloud-function-context
Affected versions: 3.1.6, 3.2.2 and older unsupported versions
Fixed in version: 3.1.7, 3.2.3

CVE-2022-22965

Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework:spring-beans
Affected versions: all versions before 5.2.20, all versions before 5.3.18 
Fixed in version: 5.2.20, 5.3.18

Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgrade spring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).

Which systems does these affect?

CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.

CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:

  • JDK 9 or higher is used as the runtime environment
  • Apache Tomcat is used as the Servlet container
  • The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
  • There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled

Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.


Why do these threats demand an urgent patch?

Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

CVE-2022-22963:

$ mvn dependency:tree | grep spring-cloud-function | grep compile
[INFO] +- org.springframework.cloud:spring-cloud-function-core:jar:3.1.2:compile

If you see any response lines, check the version: if it’s below 3.1.7 (as in the above example) or, if using 3.2.x, below 3.2.3, you may be affected.

CVE-2022-22965:

$ mvn dependency:tree | grep spring-beans | grep compile
[INFO] +- org.springframework:spring-beans:jar:5.3.11:compile

If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.


My system has the vulnerable spring cloud function library — how can I mitigate the risk?

There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.

CVE-2022-22963:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-function-core</artifactId>
        <version>3.1.7</version>
    </dependency>

Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.

CVE-2022-22965:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>5.3.18</version>
    </dependency>

Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 

  • To do a scan from the command line using the Meterian CLI scanner
  • To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.


Are Meterian applications affected by the spring vulnerability?

We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.   

Related references

CVE-2022-22963

CVE-2022-22965

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

Visibility is vital if we are to improve safety and trust in open source

viviandufour, , , , Leave a comment
Image shows an observation deck, but the panorama is veiled behind white light or mist showing blank skies. Do we know or see what we are building in our digital world?

Photo by Kate Trysh on Unsplash

Recent high profile cyber security incidents have reinforced the importance of cleaning up the open-source software supply chain. From Heartbleed to the Apache Software Foundation’s Log4j vulnerability, these highly publicised incidents have exposed the threats associated with the software supply chain.

Open source security vulnerabilities are nothing new. Heartbleed was a security bug in the OpenSSL cryptography library that affected many systems. Similarly, Log4Shell is a severe vulnerability, however in the case of Log4j the number of affected systems could well run into potentially billions. Many cybersecurity experts have characterised Log4Shell as the single biggest, most critical vulnerability of the last decade.

These incidents have brought into sharp focus the risks and galvanised a range of responses at national and international level. It even prompted the White House to convene an Open Source Software Security Summit in January that was attended by leaders from global technology companies including Google, Meta, Apple, and Cisco. Members of the open source community were also represented at the summit, as well as US government agencies, including the Cybersecurity and Infrastructure Security Agency, the National Security Council and the National Institute of Standards and Technology.

The gathering may have been precipitated by the Log4Shell vulnerability, but the wider context was clear. How do we ensure source code, build, and distribution integrity to achieve effective open source security management?

Open source under the microscope

Technology companies have been using open source for years as it speeds up innovation and time to market. Indeed, most major software developments include open source software – including software used by the national security community.

Open source software brings unique value, but it also has unique security challenges. It is used extensively, however, the responsibility of ongoing security maintenance is carried out by a community of dedicated volunteers. These security incidents have demonstrated that the use of open source is so ubiquitous that no company can blindly continue in the mode of business as usual. Recent research showed that 73% of applications scanned have at least one vulnerability[1]. These can be buried deep in the open source software supply chain that software-driven businesses rely on for basic functionality and security to accelerate their time to market.

The known unknown

The concept of known knowns, known unknowns and unknown unknowns has been widely used as a risk assessment methodology. When it comes to cybersecurity and the voracity of threat actors to exploit vulnerabilities, it is a useful analogy.

Let’s take Apache Log4J as an example. Companies often create products by assembling open source and commercial software components. Almost all software will have some form of ability to journal activity and Log4j is a very common component used for this.

How do you quickly patch what you don’t know you have?

Java logger Log4j 2 – A zero-day vulnerability

Log4J was originally released in 2001, and over the last 20 years it has been used in billions of software developments and applications across the world. For logging incidents within software, Log4j is used by everything from the humble 404 error message, gaming software such as Minecraft, and Cloud providers such as iCloud and Amazon Web Services, as well as for all manner of software and security tools.2 On 9 December 2021, the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves across organisations as security teams scrambled to patch the flaw. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations.

However, herein lies the problem. How do you quickly patch what you don’t know you have?

Often in the race to innovate, the first thing sacrificed is up-to-date documentation. Without it how does a company know if Log4J is integrated within its application estate, let alone know if it has been previously patched.

Improving safety and trust when speed is of the essence

If we are to increase safety and trust in software, we must improve transparency and visibility across the entire software supply chain. Companies should have the ability to automatically identify open source components in order to monitor and manage security risk from publicly disclosed vulnerabilities. A software bill of materials (SBOM) should be a minimum for any project or development. Without such visibility of all component parts, security teams cannot manage risk and will be unaware, and potentially exposed, to dangers lurking in their software.

Case study – Full Visibility within an Hour

To give an example; one of the largest UK based financial services company with millions of customers across the world discovered it had Log4J embedded within dozens of in-house developed software projects. Having seen the first reports of the vulnerability at the start of the business day, within an hour the security team had identified projects using Log4j and were able to start work on follow up activities. By the end of the day, the entire business had a concise list of projects at risk, some of which were already remediated.

How was this achieved?

The company had automated tooling integrated into their software development environment with comprehensive component security. This enabled them to quickly identify those software projects which depended on the affected log4j component.

This visibility allowed the company to devise remediation plans to mitigate the risks of the vulnerability in Log4J. The company was able to target valuable resources across multiple locations to ensure fixes were applied quickly to critical business applications within just a couple of hours. While they were implementing an action plan based on the organisation’s use of Log4j, some of its competitors without such comprehensive tools were still in the information gathering stage.

Innovating securely

As organisations continue to innovate at pace in order to reduce time to market, the reliance on open source software continues to increase. However, when the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted.

The White House has taken an important first step in trying to identify the challenges present in the open source software supply chain and encourage the sharing of ideas on ways to mitigate risk and enhance resilience. Organisations can and should take advantage of the many benefits that open source software can deliver, but they must not do it blindly. Ensuring you know the exact make-up of your technology stack including all the component parts is an important first step. Choosing discovery tools that have the widest comprehensive coverage is important, and so too is the flexibility to grade alerts so that only the most pressing threats are highlighted. This avoids ‘alert fatigue’ and enables security teams to focus resource where it matters most, putting organisations in a good position to act fast when vulnerabilities are discovered.

Hackers faced with stronger security defences will continue to turn their attention to the weaker underbelly of the software supply chain. Now is the time for organisations to implement integrated and automated tooling to gain comprehensive risk control of components in their open-source software supply chain. Only by increasing visibility, coverage of known unknowns and transparency can companies stay one step ahead.

1 Meterian research from aggregated and anonymised data of 2044 scanned software applications in 2020.

2 “What is Log4j? A cybersecurity expert explains the latest internet vulnerability”, The Conversation, Dec 21, 2022, https://theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896

Visibility is vital if we are to improve safety and trust in open source

An introduction to the world of SBOMs

viviandufour, , , Leave a comment 
3 minute read

We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain. 

Photo by Raymond Rasmusson on Unsplash

What is an SBOM?

SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below. 

Altova Third Party Software License Notice

However, modern SBOMs are “machine-readable”.  They follow a strict specification that can be understood by a computer. 

What machine-readable formats are used to publish SBOMs?

The most commonly used formats to define a SBOM are:

  • CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
  • SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
  • SWID, another ISO/IEC industry standard used by various commercial software publishers.

All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.

Why are SBOMs important? And how are they useful?

As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk?  With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.

As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information.  You probably want to be in the first group of companies 🙂

Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated.  The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers.  This not only impacts the companies that have direct sales to the US government but also their own software suppliers.  As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain.  This “ripple effect” will be significant for many industries. 

It’s important to consider how software products you produce can meet basic security requirements and how the associated software security information is produced and managed in your organisation.   Similar legislation has already been proposed in Europe since the publication of  “Guidelines for securing the IoT” by ENISA (hint: SBOMs are required) and the ETSI EN 303 645 global standard for consumer IoT security, which is based on the UK government’s Code of Practice.  See also the recently published Product Security and Telecommunications Infrastructure (PSTI) Bill and more to come from the UK government to improve the UK’s cyber resilience.

How should SBOMs be handled?

Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky.  Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier. 

There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:

  • SBOMs need to be shared securely,
  • they need to be accessed only by the authorised parties, across organisational boundaries, and
  • they should not be tampered with.

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.  

Why bother with SBOMs now?

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.  In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks.  Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?

Photo by Susan Q Yin on Unsplash

Get started with SBOMs

The need for SBOMs is already high. Level up your open source software security and implement this requirement. Check out the SBOM capabilities in Meterian-X platform’s approach to DevSecOps.

An introduction to the world of SBOMs

Cybersecurity and IoT: Health Care and Well-Being in our Shared Spaces

viviandufourLeave a comment

Last updated: 07/07/2021

As the extraordinary situation of the COVID-19 crisis continues and more such supervirus incidents will occur, the benefits that IoT can provide will be even in more demand.  We are already seeing how IoT plays a significant role in modernising healthcare and disaster prevention, public safety and security, supply chain, and manufacturing and production.  

The Good We’ve Seen

In Hong Kong, the government has deployed smart wristbands to monitor city residents1 quarantined inside their homes.  Accelerating the timely discovery of outbreaks, these smart medical devices, powered with internet of things (IoT) technology, play an important role in containment of outbreaks like COVID-19 and prevent future pandemics.

Prior to COVID-19 pandemic, Japan was preparing for Tokyo 20202, the smartest Olympics ever with self-driving cabs to transport guests between sports venues, robotic guides, immersive virtual reality and crowd control directed by artificial intelligence.  Getting ready to welcome 11,000 athletes with 4 to 7 million on-site spectators from Japan and all over the world, this would have been a wonderful showcase of IoT tech and applications from a country that is already a technological leader in robotics and consumer electronics.  Unfortunately, the event is postponed 12 months, though the Olympic Committee resolves to have the games, it’s not clear how much of IoT tech applications will be used.

As public venues have been opening up in the past several weeks, there is a serious challenge of getting business going and the health and safety of people using the same facilities.  How can public toilets be kept safe and clean for everyone to use?  A common need at medical centres, restaurants, shopping malls, and any city where visitors would rely on public toilets. One new IoT company on the scene, Inferrix, has a solution for the “COVID Secure Washroom”, as described on their website: Inferrix wireless edge-intelligent sensors on the washroom doors show a red light to alert visitors if the washroom is unsafe to use. Any washroom can be installed in less than 1 hour.  We can easily imagine its application to be useful in office spaces near shared kitchen areas or study areas of public or university libraries as well.

When we reflect on the role that IoT played over the course of the pandemic, there are more notable instances. For example, telehealth consultations meant that there was a reduced risk of transmission that would otherwise have been prevalent with face to face consultations. Secondly, robot assistance is used to disinfect contaminated areas and objects, both protecting health carers and giving health carers more time to care for their patients. China was the first country to use Danish made UVD robots using IoT and help to disinfect treatment areas in nursing homes and clean patient rooms.

The Not So Good

In a 2019 study of security of IoT devices3, data revealed that more than twice the number of vulnerabilities were detected compared to six years earlier.  As covered in in our last blog post, cyber attacks from IoT risks have surged 300% and the UK and US are catching up on regulations to ensure companies safeguard devices. In March 2020 researchers found4 that more than half of all internet of things (IoT) devices are vulnerable to medium- or high-severity attacks, with 98% of all IoT device traffic being unencrypted.

As we’ve seen during the COVID-19 crisis, even when everyone else was rallying together, cyber criminals targeted vulnerable organizations in the health sector: data-stealing ransomware on US pharma company5 and Europe’s largest private hospital6, Czech republic hospital’s computer systems were attacked when their focus was on running coronavirus tests, and in the UK two construction companies building emergency hospitals were hacked7.

Such attacks can become more sophisticated and more dangerous to individuals using new health technology apps and devices used to provide medication or daily survival needs.

Bringing Tech Out for Good

Connected devices are available using cellular connectivity which are allowing doctors to rely on patients to use connected out-of-the-box devices for special readings to be sent directly to the doctor from the device (temperature, blood pressure, glucose meters).   Such technology is not limited to medical practitioners and is already available for anyone.  A user created a smart system to monitor his diabetic brother’s blood sugar8 (glucose) levels using an app, a data logging platform that processed data from his brother’s glucose sensor to make his own healthcare monitoring system.

Similarly, Australia saw its first ‘virtual hospital’9 open shortly before the COVID-19 pandemic hit through Royal Prince Alfred Hospital (RPA) in Sydney. Data from pulse oximeters used to measure oxygen saturation levels and heart rates along with armpit patches to track temperature were transmitted to the hospital. In addition, video-consultations allow coronavirus patients to receive the care they need without the risk of transmission. 

Recently, we have seen evidence of health providers recognise the risks surrounding IoT devices and the need to incorporate security standards to protect against malicious hackers. For example, University Hospitals of North Midlands NHS Trust has opted to trust Ordr with providing a systems control engine (SCE)10 which will locate and secure every connected device. This includes Internet of Medical Things (IoMT), Internet of Things (IoT) and Operational Technologies (OT) devices.

Security, safety, and data privacy considerations are important aspects of designing, building and maintaining such systems to protect the identity and well-being of the individual.  We’d hate to think about incidents where devices give wrong information due to a malicious actor – getting the wrong medication, dosage, or advice could have serious, even lethal consequences.  Having IoT devices and apps to create a safer world requires more scrutiny and protective measures designed as part of the solution.  As many of these solutions will be designed for one person’s use, customised to their medical needs or specific daily routines, it’s essential they are maintained, updated, and when no longer maintainable that they are properly turned off and disposed of.

Check out IoT For All Podcast with Christopher Schouten of Kudelski Group11.  He talks about necessary considerations to secure IoT projects, making sure they can scale as well as be practical in protecting what is valuable. 

Although the transformational journey to an IoT world seems daunting, the capabilities of IoT to bring high-tech care and consultancy out of the clinic and into homes and vulnerable communities across the world presents a thrilling opportunity.  Health care and IT experts, technicians, research scientists and security experts are collaborating, as are carers, policy makers and administrators.  Altogether, the confluence of tech and human intelligence will continue to evolve and strive to protect all that is worth protecting.  COVID-19 and cybercrime are making seismic shifts in worldwide health and safety, threatening our prosperity. Let’s defend the world, use technology for good and build the world we want.

If you are a developer or have a software development team using open source components, learn how  Meterian automates monitoring of software applications for open source risks and vulnerabilities.  Read about Meterian-X: Invisible Security for your Open Source Security Management in IoT systems and devices.

1 Doffman, Zak. “Coronavirus Police Surveillance Tags Are Now Here: Hong Kong First To Deploy.” Forbes, 17 March 2020, https: //www.forbes.com/sites/zakdoffman/2020/03/17/alarming-coronavirus-surveillance-bracelets-now-in-peoples-homes-heres-what-they-do/?sh=227b12984533

2 Hallet, Rebecca. “Tokyo on track for smartest Olympics ever”. Raconteur, 20 February 2020, https ://www.raconteur.net/technology/internet-of-things/iot-tokyo-2020/

3 Coble, Sarah. “Vulnerabilities in IoT Devices Have Doubled Since 2013”. Info Security, 17 September 2019, https ://www.infosecurity-magazine.com/news/vulnerabilities-in-iot-devices/.

4 O’Donnell, Lindsey. “More Than Half of IoT Devices Vulnerable to Severe Attacks”. threat post, 11 March 2020, https:// threatpost.com/ half-iot-devices-vulnerable-severe-attacks/153609/.

5 Whittaker, Zack. “Hackers publish ExecuPharm internal data after ransomware”. Tech Crunch, 27 April 2020, https: //techcrunch.com/2020/04/27/execupharm-clop-ransomware/.

6“Europe’s Largest Private Hospital Operator Fresenius Hit by Ransomware”. KrebsonSecurity, 6 May 2020, https: //krebsonsecurity.com/2020/05/europes-largest-private-hospital-operator-fresenius-hit-by-ransomware/.

7 “Coronavirus: Cyber-attacks hit hospital construction companies” BBC News, 13 May 2020, https: //www.bbc.co.uk/news/technology-52646808.

8 Anx, Quintessant. “Healthcare IoT: Monitoring Diabetes with Logz.io” Logz.io, 11 December 2018, https: //logz.io/blog/healthcare-iot-monitoring/.

9 Minion, Lynne. “‘Flattening the curve’ with virtual care in Australia'” Healthcare IT News, 30 June 2020,  https: //www.healthcareitnews.com/news/europe/flattening-curve-virtual-care-australia

10 Crouch, Hannah. “University Hospitals of North Midlands deploys Ordr cyber security solution”. digital health, 6 May 2021, https: //www.digitalhealth.net/2021/05/university-hospitals-of-north-midlands-ordr/

11 “Security Challenges in the IoT Landscape | Kudelski Group’s Christopher Schouten”. iot for all, 5 May 2020, https: //www.iotforall.com/podcasts/e064-iot-security-considerations.

Cybersecurity and IoT: Health Care and Well-Being in our Shared Spaces