Last five years have shown several large security vulnerabilities that can create real-world safety implications, such as the Stuxnet worm that reportedly ruined one-fifth of Iran’s nuclear centrifuges. Shinto Joseph, operations and sales director, LDRA Technology Pvt Ltd, speaks with Dilin Anand of EFY about the increasing real-world implications of embedded software testing
Q. How has testing embedded software evolved over the years to keep up with newer security vulnerabilities?
A. Analytical tools are primarily used for finding defects in a system. While earlier this was done from a safety perspective, it is now being done from a security perspective. Ultimately, what is required here is finding the defect in a system through end-to-end analytics, going through the code and looking for malicious content, searching for vulnerabilities and also generating test cases so as to go through all possible permutations and combinations of potential problems.
Q. How do vulnerabilities make their way into the code in the first place?
A. In a security paradigm, no one deliberately creates a system for others to hack. However, the designer might have missed taking all necessary precautions. And, there is always the chance that the hacker is smarter than the designer. Either of these makes the system vulnerable. If somebody is designing a system, it is his or her responsibility to make sure that the system is secure. Today liability clauses force designers to make responsible designs.
Q. How can design engineers play safe here?
A. My advice to engineers is that they need to handle these issues at the design level itself, rather than wrapping the system into folds of security solutions. At the end of the day, even if the system is not strong internally, in case of an attack, it should be resilient enough to be able to come back to normal.
For consumer devices like mobile phones, attacks happen all the time but these are comparatively not as serious as an infrastructure hack. When we consider large power-distribution systems, a nuclear reactor, railway network or telecom network, these factors are very important. Somebody has to make these designs safe, test the systems for vulnerabilities and enforce internationally-acceptable coding design guidelines from a safety or security perspective.
Q. What is the relationship between a safety and a security issue in an infrastructure?
A. Security and safety issues are often interlinked. For example, in a nuclear reactor, a security breach can result in a large safety issue. Security vulnerabilities can result in a blast in the reactor, which could convert the power station into a bomb after that, resulting in a major safety issue.
Q. I understand that memory limitations have an effect on testing software in embedded devices. But is memory, or the lack of it, still a problem in 2015?
A. People often say that memory is unlimited, but it is not the case. Most systems are designed for optimal resources (with respect to hardware and software) and for optimal size and form factor. People are interested in finishing it with the bare minimum, as they have to pay for each bit of extra memory. While this amount might be negligible when looking at just one or two chips, it adds up to a lot when you consider the quantities involved in the mass production and shipping of a consumer product.
Q. How is this situation different if we look at infrastructure systems where memory would not be mass produced?
A. An infrastructure system requires high-end reliable memory and every gigabyte (GB) costs a lot. This causes designers to put a cap on memory. However, many new techniques are coming up. For example, experts have suggested proteins to be the next memory material as semiconductor materials seem to have reached their limit of how small the memory could be.
Q. What are the challenges faced by designers here?
A. Many times we see that a design gets implemented in large programs five to eight years after work started on these. The design team takes care of issues that were prevalent 15 years ago. However, once the program takes shape, different problems arise all together. So, you need to test the system for those changed scenarios as well.
Also, security was not much of an issue ten years ago. Today, it is the first design consideration for any system. You may even end up testing systems that are not designed for large memory.
