Trucking companies are on the receiving end of products like ELD, telematics, dash cameras and so on. Those product vendors come with their own hardware and software, widening the attack surface for trucking companies that use them. In the event of a cyberattack, those products could be a hacker’s in into a trucking company’s systems, and many are targets because trucking is critical to the economy.
That’s why Amadou Kane, senior solution architect/engineer of automotive cybersecurity at VicOne, said he doesn’t abide by the old adage “trust but verify.” He said trucking companies should never trust and always verify when it comes to security.
Trucking companies may typically have IT teams who manage their enterprise security for things like transportation management systems, but even when they’re not the maker of a product they bring into their systems, they still have a responsibility to ensure security of those third-party solutions.
Managing third-party product security
Kane told the audience during a recent session at the National Motor Freight Traffic Association Cybersecurity Conference, that the first step to managing security of third-party products within a trucking company’s environment is requesting the SBOM (software bill of materials) from suppliers.
“If you can have access to the binaries of those firmware and do the scans yourself, that is the most ideal situation,” he said.
Kane said other elements to request include vulnerability reports, the Crypto BOM report (Cryptographic bill of materials, which is an inventory of all cryptographic elements in a software application, system, or product) and the HBOM (hardware bill of materials).
“The focus tends to be on products, usually just on software vulnerabilities, and we tend to kind of brush off the hardware portion, but that also needs to be part of the equation,” he said.
Art Ocain, Airiam vice president of cybersecurity and incident response, asked Kane what carriers on the receiving end of these products can do when they don’t have access to the product code?
Kane said there should be a team responsible for monitoring data coming in from CAN bus traffic, telematics traffic, server logs, API logs and any other connected applications. He said teams need to monitor the vehicle communication system and the communication between the vehicle and the cloud.
“Then you need to have some detection rules,” he added. “Certain organizations have certain use cases that are very specific to them, so you need capabilities within your SOC (security operations center) to create these detection rules that allow you to monitor these use cases that are relevant to you.”
Most importantly, he said, carriers need a SOC that can act as an XDR (extended detection and response) that can perform cross-data correlation because data streams are coming from different data sources, and an XDR unifies data from multiple security layers.
“If you cannot cross correlate them, then it's almost useless. You're missing out on a lot,” Kane said. “You need that context, and that context comes from the first data correlation.”
Training an incident response team
Kane said there are differences between enterprise incident response and product incident response. They’re the same in that you want to minimize impact, ensure continuity and improve cyber resilience, but implementation is different.
“When we look at enterprise, if there is an incident, you can usually just isolate a system or rebuild your system,” Kane said. “When it comes to vehicles or products, you cannot just simply do that. If there is a large-scale instance, you cannot rebuild all vehicles on the road; you cannot just shut down all the vehicles.
“There is a safety-critical element that is tied to product incident response,” he added. “On enterprise side, delays are acceptable, but in product side, people’s lives are at risk so it’s more time sensitive.”
It requires a more holistic approach.
That means the incident response team has to work with the product security operations team, and there are huge gaps between the two that result in inefficiencies in terms of how they respond to incidents, Kane said.
He said IT, operational technology and product need to converge because attackers will find and exploit the gaps between them.
“That's a disservice from a security perspective to treat them as separate entities because they're tied together in so many different ways,” said Ben Wilkens, cybersecurity principal engineer at NMFTA.
Kane said it’s all connected, from the manufacturing of the products to the customers implementing them, so it’s important to have a more comprehensive incident response plan to cover all areas.
“Additionally, it's important to know that maybe on the enterprise side, it will be more acceptable when you have a static incident response plan,” he said. “In products, you really need a more living incident response plan, meaning it has to adapt; it needs to change. The threat actors change, the attack surfaces change constantly, and it needs to change with it.”
Secure by design is No. 1, Kane said.
A critical element is integration of threat intel within the deployment lifecycle so developers can make changes as needed, Kane said. He said having integrated vulnerability management within the CI/CD process (continuous integration and continuous delivery, a set of automated practices for software development that speeds up and makes code releases more reliable) to allow for vulnerability scans is also important.
“Usually what we see is people just focus on source code scanning … they think source code scanning is important, but source code scanning is very quote, unquote static in a way,” Kane said. “New vulnerabilities will come long after you develop and sell the product. Therefore, binary scan is important, because once you deploy those products, you can continue to monitor them for vulnerabilities. With a source code scan, you cannot do that.”
Kane said sometimes developers leave backdoors open when software is deployed for debugging purposes, and that becomes a problem. So it’s also crucial, he said, to add backdoor scanning capabilities within vulnerability management platforms.
Lastly, is workbook automation.
Kane said there is a process that should be followed when there is an incident, whether it's during the development phase, coming from threat Intel or coming from a vulnerability scan. Examine and analyze the threat or incident to determine if it’s relevant and if there is a fix needed. Then, determine who owns the issue, and it could be a supplier or an OEM.
Understanding that process and updating the workbook for that process, he said, is often overlooked in incident response training.
Changes in attacker mindsets
On the product side, Kane said he has heard more talk from criminals on the Dark Web about fleet-scale attacks, and as more Class 8 electric and autonomous vehicles come into the market, those attacks will expand.
