SPEAKERS

Paul Kearney is part-time Professor of Cybersecurity in the Networks and Cybersecurity Department at Birmingham City University (BCU). He has had a long and varied career in research and development in industry, and has previously worked for British Aerospace (BAe), Sharp and British Telecom (BT). His research interests include security and trust architectures for large-scale dynamic IoT systems, monitoring cybersecurity in the smart home, model-based security risk assessment, and application of data science and AI to cybersecurity problems. In addition to his role at BCU, Paul is a member of the Advisory Board of METCLOUD, an active contributor to the activities of the IoT Security Foundation, a visiting research fellow at EBTIC, Khalifa University, Abu Dhabi, an expert reviewer for the Horizon Europe programme, and a consultant on cybersecurity R&D.

Presentation: Towards Continuous Assurance of IoT Cybersecurity (provisional)

Future economic prosperity requires a thriving market in IoT products featuring rapid innovation in response to end-user needs. However, this cannot be achieved at the expense of exposing stakeholders to undue cybersecurity risk. Vendors have a responsibility to provide products that are fit for purpose security-wise, with clear guidance and constraints regarding secure usage. Similarly, customers must select products with appropriate security properties, and to operate them securely, often as part of larger systems. This requires confidence in the statements from vendors about their products and development and production practices

The existing market resembles the ‘wild west’, expanding and developing rapidly, fuelled by pioneering spirit, but lawless and with many innocent casualties as a result. This situation cannot be sustained, but how can order be achieved without sacrificing innovation and dynamism? The current product certification ‘solution’ involves a static assessment of a specific product under specific conditions. The associated processes are lengthy, ‘paper heavy’, and resource and capital intensive, which acts as a disincentive to their adoption. Certified products are likely to be uncompetitive by virtue of being expensive and late to market.

A new approach – call it continuous assurance, or perhaps active certification — is required that can reduce costs, automate maintenance, be scalable, sustainable, and timely in delivery. Properties of such an approach include the following:

• Meeting these conditions will need an increasing degree of automation and/or software support, which in turn requires mathematical formalisation of concepts to allow them to be represented in a form that is understandable by people and machines and can be reasoned about by both.
• Claims (i.e. statements about security properties of a product) should be modular and scheme-independent, so that the same product can be certified according to additional schemes with minimal effort.
• Claims should be composable in the sense that, a claim proven about a component can be used to support proof of a claim made about the system in which the component is used.
• The approach needs to apply over the full product lifecycle, from requirement to retirement. In particular:
  • Security by Design should be baked into the development process. It needs to be compatible with software development processes including the various flavours of agile and DevSecOps.
  • Initial certification should make use of evidence gathered during Development. Such evidence should include software and hardware bills of materials (SBoM, HBoM) identifying incorporated external components and dependencies and their certification status or other evidence of trustworthiness.
  • Certification should not be based on evaluations performed on a snapshot of an evolving product and operational context at a point in time. Rather, validation should be performed continuously, on-demand, or in response to events.
  • Key evidence upon which certification depends should be identified and monitored. Certification status is conditional on these remaining true. If this is not the case, it may be necessary to return temporarily to the Development stage. An example is discovery of a new vulnerability that affects a library identified in the SBOM.
  • If a condition invalidating certification is discovered during the operational phase then processes should be launched to remediate. Pending resolution, the product’s certification status could be downgraded, or withdrawn if remediation is not possible or will take a significant time.
  • The behaviour of device instances should be monitored during Operations. Deviation from expectations could indicate e.g. exploitation of a previously-unknown vulnerability or that assumptions on which certification was based are not valid. Either of these could affect certification status.

The talk will explore these and related issues, and briefly review related on-going initiatives, with the aim of stimulating debate about fruitful ways forward.