Products for various M2M (machine-to-machine) systems, including industrial control systems (ICS), building automation, transportation, medical equipment, and telecommunications, cannot be protected using overlay security tools, because antivirus protection cannot be installed on a PLC, a vehicle electronic control unit, or a cellular base station. The ability of such solutions to resist cyberthreats depends entirely on their environment and their own resilience to attacks (security by design). However, most modern automation systems and smart solutions are so technically complex that even leading global manufacturers cannot independently guarantee their reliable protection.
The problem
The solution
A comprehensive approach to security, encompassing the following stages:
- Conducting an in-depth security assessment of M2M systems, including multi-level research into the technological components used;
- Prioritizing the security issues identified;
- Describing potential attack vectors and possible consequences for the device, infrastructure, and business;
- Developing remediation options for the issues identified, and compiling a list of alternative measures to mitigate risks associated with these issues being exploited in attacks by malicious actors.
Target audience
- Developers and manufacturers of various M2M and other specialized products for ICS, IoT/IIoT, transportation (automotive, rail, maritime, aviation), medical devices and equipment, telecommunication systems (cellular base stations, core network systems), etc.
- Developers of M2M system components: individual control units, chips, network protocol stacks, firmware, operating systems, software execution environments, license enforcement tools, and other software or hardware modules.
- Owners of such products.
Contents
The issue
A common cybersecurity-related challenge across diverse M2M systems, such as ICS, building automation, transportation, medical equipment, and telecoms, is that using overlay security tools is difficult or impossible. Hardware constraints and architectural choices, strict response-time, fault-tolerance, and resource-consumption requirements, rare and exotic operating systems, and other technical issues make developing or adapting supplementary security technologies impractical, excessively expensive, or technically impossible.
The ability of such M2M systems to resist cyberthreats depends entirely on their use cases, operational environment, and resilience to attacks (i.e., security by design).
The use case scenarios for most product lines are steadily getting more numerous and complex, and manufacturers are increasingly designing their products, even niche and highly specialized ones, with flexible capabilities for modifying and expanding functionality. In large part, this is accomplished by transitioning from highly specialized products to versatile solutions when selecting components. This, in turn, results in products incorporating hidden functionality that not only remains undocumented for users, but, in our experience, is often unknown even to the manufacturers of the final solutions.
Furthermore, developers often make incorrect assumptions regarding the use cases and possible operating environments of their products: users invariably do «the wrong thing, in the wrong way, and in the wrong place.» For instance, it’s virtually impossible to guarantee that industrial automation equipment and other specialized hardware and software systems remain in an isolated environment 100% of the time, even when regulations and internal policies require this. Even when a vendor is confident that a system is reliably isolated and that users make no mistakes and do not expose critical systems to cyberthreats (something we have never seen in our many years of practice), there is always a risk of supply chain compromise: malicious modifications can be introduced along the way, as the equipment is transported from the manufacturing plant, in a service workshop, or via an engineer’s laptop or diagnostic equipment.
This means that the only truly effective strategy for reducing cybersecurity risks is investing in the inherent (built-in) cybersecurity of products — both those being developed and those in operation. Ideally, a manufacturer should strictly follow the security-by-design methodology in every aspect of designing, maintaining, and developing a product. In practice, however, such cases are virtually non-existent.
Even when the developer does everything properly with respect to their own code and makes the right architectural choices, uncontrollable third-party components remain an issue. An RCE vulnerability in a modem can become a MitM attack vector that cannot be mitigated at the end-solution level; furthermore, if the modem is integrated into an SoC, such a vulnerability becomes a threat for the entire solution as a whole, thwarting any attempts to protect the OS and application code executed by the application processor.
From an information security perspective, relatively small M2M solutions in practice are extremely complex systems that include one or more chips and extensive stacks of «common» components implementing network communication protocols, runtime environment functions, license enforcement, and more.
Independently performing a comprehensive security assessment of all these software and hardware components with sufficient breadth and depth to identify and remediate all major cybersecurity risks is beyond the capacity of even the largest developers and global leaders in their respective product segments.
For products used in transportation, energy, telecommunications, building automation, healthcare, and other cyber-physical environments, these risks are particularly high. A vulnerability in a single component can affect not only the device itself but also adjacent systems and industrial equipment, threatening both functional and physical safety.
What we offer
We offer in-depth research and detailed expert security assessments, in which we identify and demonstrate security flaws in a product and its components, determine which components are at greatest risk, show how the vulnerabilities identified can be exploited in real-world attacks, and analyze the potential impact. We propose remediation strategies and options for refining the customer’s product architecture, and work with component vendors to help them effectively remediate vulnerabilities affecting the security of the end solution.
Early in product development
The service is especially helpful in the early stages of product development. By examining customer-selected third-party components before mass production, we help remediate vulnerabilities identified in these components or mitigate the risks of their exploitation before the product enters the market.
During pilot or industrial deployment
The service can also be of help to enterprise customers of end products during pilot or industrial deployment stages, acceptance testing, and certification — for instance, before commissioning.
Following the release of new firmware versions
For developers, the service helps mitigate the risk of incidents after releasing new firmware versions with substantial functional changes, such as introducing remote management or altering the architecture of interaction with adjacent systems.
The assessment outcome
The assessment outcome is not a generic «pass/fail» conclusion, but a multidimensional, thorough evaluation of the product’s security posture against diverse attack vectors, which enables the customer to evaluate the severity of the vulnerabilities identified within their own coordinate system and risk model, while receiving assistance from leading cybersecurity experts in finding effective ways to remediate the security issues most critical to them.
What we do
The work begins with defining the scope and boundaries of the assessment: the device, module, firmware, service software, protocols, hardware interfaces, any cloud components, use cases, and interactions with the environment.
The customer then selects the testing formats:
- Black box, in which the analysis is conducted without access to internal information about the product, from the perspective of an external attacker;
- Grey box, in which the analysis is conducted with partial access to documentation, firmware, configurations, and user accounts;
- White box, in which in-depth analysis is conducted with access to architecture specifications, the source code, schematics, debugging interfaces, and service tools.
Testing formats are selected based on the customer’s objectives and resources: while they do not affect the quality of the analysis, they do influence its duration and cost, since less source data available for analysis means more time and resources required.
We conduct testing in a secure environment: on a laboratory test bench, a test device sample, an isolated infrastructure segment, or in a specially prepared customer environment. This enables us to test realistic attack scenarios without any risk to industrial, client, or production infrastructure.
The assessment can cover all product layers and any aspects of the product’s operation.
Product architecture and logic
We evaluate the components that make up the product, how these components interact with each other and adjacent systems, and where trust relationships reside. This enables us to identify weak spots in the solution’s architecture, such as excessive privileges, insecure data communication, lack of segmentation, inadequate access control, and to assess its resilience against the exploitation of potential vulnerabilities across various functional and technological components.
Software and firmware
We examine application components, firmware, bootloaders, update modules, command handlers, and mechanisms for storing configurations, keys, certificates, and event logs. The objective is to identify implementation flaws, vulnerabilities, undocumented features, and ways to modify software or bypass security mechanisms.
Hardware and physical interfaces
We investigate hardware architecture, service connectors, debugging interfaces, connection ports, removable media, and other vectors of physical interaction with the device. This is crucial for equipment to which a potential attacker could gain physical access: controllers, gateways, telematics control units (TCUs), IoT/IIoT equipment, and other devices.
What the customer gets
Upon completion of the work, a comprehensive set of deliverables is provided, which can serve as a roadmap for decision-making regarding product refinement and security enhancement.
The deliverable package includes:
- A technical report containing:
- Descriptions of identified vulnerabilities;
- Vulnerability severity assessment and potential impact of exploitation on the product and associated infrastructure;
- Proof of reproducibility for significant vulnerabilities*;
- A map of possible attack vectors with unauthorized impact scenarios and prerequisite conditions;
- Actionable recommendations for remediating the issues identified;
* The PoC code is provided to the vulnerable code developer only.
- An executive summary presenting key risks and findings;
- A final presentation of assessment results;
- A re-assessment following remediation, if required.
For technical teams, we prepare a report with the information needed to analyze and remediate identified issues: affected components, exploitation prerequisites, possible causes, and recommendations on modifying the product’s logic, configuration, update mechanism, protocol implementation, or interface protection.
For executive management and product owners, we provide a concise summary: key risks, potential business impact, priority focus areas, and recommended risk mitigation steps.
As a result, the customer gains an objective understanding of how resilient the product is to modern attacks, which components require refinement, which risks must be addressed as a first priority, and whether the hardware and software solution is ready for mass production, market release, pilot deployment, or scaling.
