Vehicle security is a major challenge, particularly when it comes to monitoring as part of secure operations. Our first blog post explored why this is the case and how automotive honeypots can help address these challenges. At CROWSI, we believe automotive honeypots are a valuable tool for protecting vehicle fleets and meeting regulatory requirements. However, the question remains: How should an automotive honeypot be designed?
Current research on automotive honeypots typically discusses two approaches:
- In-vehicle honeypots
- Cloud-based honeypots that simulate vehicle assets
In this post, we will discuss the first approach: in-vehicle automotive honeypots. We will explore the second approach in a future blog post.
In-Vehicle Automotive Honeypot Approaches
Current literature primarily discusses two approaches for in-vehicle automotive honeypots:
1. Dedicated Hardware Honeypots
One approach is to deploy a honeypot on dedicated hardware, either connected to or isolated from the vehicle’s main systems. While this generally allows for strong isolation from critical vehicle assets, the associated costs make it an impractical choice for most OEMs.
2. Integrated Honeypot Decoys
A more cost-effective alternative is to integrate honeypot decoys into existing vehicle hardware. In this setup, the honeypot decoy operates alongside essential vehicle applications, sharing the same resources and software stacks.
When we started developing CROWSI, we initially considered this approach. We discussed it with a security expert responsible for the security of the connectivity ECU of a major OEM. His response was clear: they would not allow software in their vehicles unless it had a direct customer use case. The reasoning was straightforward—any software can become vulnerable, and rapid patching remains a significant challenge in the automotive industry. To minimize attack surfaces, their internal policy strictly prohibited unnecessary software on their devices.
While this is certainly dependent on the security culture of the company, this perspective highlights a critical challenge with in-vehicle honeypots: A honeypot is designed to be attacked. Since it does not have legitimate interactions, any communication with it is likely malicious. If a honeypot shares hardware with critical vehicle systems, software vulnerabilities in the honeypot—especially if combined with insufficient or vulnerable isolation—could allow attackers to pivot from the honeypot to actual vehicle assets. This risk makes in-vehicle honeypots potentially more harmful than beneficial.
The CROWSI Approach: Isolated Backend Deployment
To mitigate these risks while still leveraging the advantages of automotive honeypots, we developed CROWSI with a different architecture. Instead of embedding a honeypot inside the vehicle, we place the decoy in an isolated backend deployment and integrate it with the vehicle’s ECU via a simple reverse proxy.
One might argue that the reverse proxy itself could still introduce vulnerabilities. However, several well-tested and widely used reverse proxy implementations exist. More importantly, the reverse proxy only forwards traffic to the CROWSI honeypot decoy. Any actual harmful interactions occur in the isolated backend, significantly reducing the security risks to the vehicle.
That said, a vulnerability in the proxy will always remain a risk, which is why we have published additional security considerations in our GitHub repository. These guidelines help mitigate potential risks, ensuring that the benefits of automotive honeypots outweigh any remaining risks.
While this architecture offers a secure alternative to in-vehicle honeypots, we want to be transparent and briefly discuss its limitations. For instance, a common honeypot decoy scenario is an SSH service. If an attacker expects an immediate response to a command but experiences lag due to internet disconnections, they may suspect the system is not running locally in the vehicle. Attackers expecting real-time responses may become suspicious if delays occur due to connectivity issues.
Therefore, when designing honeypot decoys in CROWSI, the overall system’s credibility from an attacker’s perspective must be carefully considered.
Conclusion
When deciding on the right approach for an automotive honeypot, we recommend starting with CROWSI. This allows you to gain the benefits of honeypot technology while keeping risks low. Over time, insights gained from running decoys in CROWSI can help you enhance your security posture, potentially leading to more secure in-vehicle decoys in the future.
We’d love to support your automotive honeypot journey. Share your thoughts and experiences with us—we’re eager to collaborate and learn together! Reach out to us, and let’s build a world where attackers can never be sure whether they’re interacting with a real asset!