I recently attended the IFSF Conference, and it was an amazing experience. The content was excellent, and I had the opportunity for several one-on-one meetings with some of the players in the market. Nuno is Senior Embedded and Application Engineer at Invenco Group.
Reflections on Old and New Protocols (A.P.I = API ?)
However, I want to share my opinion about a new trend in our industry. There’s a wave of thinking that the old protocols weren't APIs and, more importantly, that an API is simply a JSON string loosely validated by a schema.
This perspective isn’t entirely accurate. An API is an agreed-upon interface convention between two or more parties to exchange and process information. It’s not limited to JSON or any one data format; it's about establishing a well-defined method of communication.
Just as virtualization didn't start with personal computers but originated on IBM mainframes with concepts like horizontal and vertical partitioning, many modern technologies have foundations in older systems. There’s nothing inherently wrong with reinventing technology to make it more accessible and usable for a broader audience. However, it's crucial to remember that the foundational principles and decisions made by the "old timers" often have solid reasoning behind them.
Addressing Dispenser Protocols and Practical Alternatives
One of the complaints at the conference was that current dispenser protocols are difficult to implement and somewhat limited. But let's consider the alternatives.
Would we want to add CPUs and microcontrollers to dispensers that can run TCP/IP stacks, host servers, and have the memory capacity for schema validation on JSON strings? Is that a feasible expectation, and what would the security implications be?
Should the current forecourt wiring be updated to use Ethernet or its industrial variants, requiring expensive cabling and industrial ethernet switching? Or should we consider PLC communication, which can also be quite expensive? These steps might simplify software development but could introduce higher costs and complexities in hardware and infrastructure.
Security Concerns with Modernizing Forecourt Devices
Security is another critical issue. With over 20 years of experience in the forecourt industry, I've observed and sometimes collected various exploits that can affect the majority of fuel dispenser brands, including those using IFSF.
Historically, these networks have been relatively isolated, limiting communication and therefore reducing exposure to potential exploits.
By making dispensers and other forecourt devices "API-friendly" and easily accessible over common protocols, we risk making them more vulnerable to external attacks. A fuel dispenser is a highly sensitive piece of equipment. If attackers gain control of its main microcontroller, it could lead to disastrous outcomes, from causing fuel spills to permanently damaging the dispenser.
Imagine a scenario where a worm infiltrates a large retail network. Typically, malware might corrupt POS systems, but now consider the possibility that it could also brick dispensers or cause them to malfunction all at once.
Rebuilding a POS system is relatively straightforward compared to the complexity and cost of repairing or replacing physical dispensing equipment. Additionally, uncontrolled fueling initiated by a compromised system could lead to safety and environmental hazards.
The Role of Diversity and Avoiding Single Points of Failure
Some advocates of modern "API approaches" emphasize that automated tools can parse schemas and generate code automatically, making development more efficient. While this seems beneficial, it raises questions about risk. Consider what happened with the Log4J vulnerability. If a typical code construct used by automated tools introduces a vulnerability, and that same tool is widely used across payment devices, fuel dispensers, POS systems, etc., a single exploit could compromise a broad swath of the industry.
In nature, biodiversity within a species helps ensure that not the entire population is wiped out by a single disease. Similarly, a diverse ecosystem in IT can help mitigate the risk of widespread vulnerabilities.
By moving towards standardized APIs, identical protocols, and tools, we may unintentionally reduce diversity, increasing the potential impact of security flaws.
Efficient Communication and Cost Implications
From a technical standpoint, some skepticism is understandable. Communication between computers doesn’t need to be as inefficient as a JSON stream, especially in systems where performance and reliability are crucial.
Increasing computational requirements can lead to higher hardware and operational costs, which might not be justified if simpler, more efficient solutions are available.
Conclusion
While modernizing forecourt systems and making them more accessible through APIs can bring benefits, it's essential to carefully consider security implications, cost, complexity, and the reasons behind the original system designs. The decisions made in previous generations of technology often had strong rational foundations.
As we innovate, we should strive to retain the robustness, security, and cost-effectiveness that these foundational principles provide. Modernizing shouldn't mean ignoring the lessons learned through decades of experience in favor of convenience alone.
Share this:
