0

Are there any fundamental vulnerability peculiarities unique to real-time systems? Are they impervious to some vulnerabilities, due to their speed?

Here, real-time system refers to typical usage where the time constraints are very short, and delivery deadlines are similar to human reaction times. Examples include train engineering systems, car-driving systems, helicopter pilot systems, etc.

Brent Kirkpatrick
  • 950
  • 4
  • 19
  • 4
    "... due to their speed?" - a real time system is not necessarily a speedy system but can be in fact really slow. But it is a system where specific tasks have harder time constraints. But there are lots of different hard/soft real-time systems, requirements and use cases. Thus please narrow down your question to a specific use case. As it is currently I consider it too broad. – Steffen Ullrich Mar 22 '16 at 09:15
  • 1
    How does "speed" make something impervious to vulnerabilities? – schroeder Mar 22 '16 at 14:44

1 Answers1

6

Generally, if something is wrong with a real-time system, it'll go wrong upon a trigger event occurring. For example, Knight Capital had a stock trading system which responded to specific circumstances by buying stocks - when the system was pushed out without testing, it spent all their money, causing price fluctuations and the company to go bankrupt.

As a result, system correctness testing is really important - whereas with a non-real-time system, there are often ways to compensate for issues (maybe you can revert the database and redo transactions if you find a mistake has been made), that's not always the case with real-time systems, especially those with a real-world impact.

Consider systems that control traffic lights, or fly-by-wire implementations in aeroplanes. In these systems, a flaw which isn't picked up in advance can cause injury or death, and, worse, can be triggered by an unforeseen situation - can your fly-by-wire system handle failure of the GPS satellite systems? What about the sudden appearance of a number of erroneous GPS signals from a malicious agent?

This means that development and testing of real-time systems tends to be much more stringent than for other software. It's not uncommon for vast swathes of safety case data to be produced, ensuring that any potential failures result in a safe state, which depends on the system in question: for Knight, it would have been a maximum spend, for example. For Boeing, it might be that the plane alerts human pilots to a requirement to take over. For a nuclear power plant, it might involve a controlled shut-down.

Matthew
  • 27,381
  • 7
  • 91
  • 103
  • 1
    Safety testing does not necessarily include thorough security analysis. For a long time real-time systems relied on air gapping and physical access restrictions. Thankfully, the thinking has changed. An illustration: safety testing may have checked for consequences of two commands being sent together, while it did not include the case of a long crafted command sequence. – Deer Hunter Mar 22 '16 at 11:44
  • Real-time systems tend to avoid dynamic memory allocation, garbage collection and other nondeterministic features, but that doesn't make them more secure against determined adversaries. Formal verification methods, however, are of great help. – Deer Hunter Mar 22 '16 at 11:49
  • 1
    Sadly, this is true - it's only been in the last few years that security has been acknowledged as one of the safety critical aspects of systems. Ideally, engineers should be designing in handling for malicious inputs, as well as potentially erroneous ones (consider the contrast between a failing sensor, fluctuating between states, but reporting at a regular rate, and a malicious sensor, sending valid data at high rates). – Matthew Mar 22 '16 at 12:08