Why Software Quality Standards Matter For Industrial IoT

9 Java Programming Myths Busted

Whenever the Internet of Things (IoT) is the subject, the discussion tends to veer off into topics of security and safety. When it's the industrial IoT being talked about, the question of how to keep the company running enters the conversation, too. It all boils down to quality, and how it's defined for software.

Bill Curtis, a Fellow of the IEEE, is one of the people who has long defined what quality means for software. While at the Software Engineering Institute at Carnegie Mellon University, Curtis led the development of the Capability Maturity Model, a software quality standard long used by the U.S. military.

Today, Curtis is director of the Consortium for IT Software Quality (CISQ), an industry group that is, according to its website, "comprised of IT executives from the Global 2000, system integrators, outsourced service providers, and software technology vendors committed to introducing a computable metrics standard for measuring software quality & size."

InformationWeek interviewed Curtis at the IIOT Challenges and Opportunities conference hosted by CISQ on June 22 in Orlando, Fla. We talked about the current state of software quality in the industrial IoT, and what it will take to improve the software now running the sensors, devices, and processes that form a growing portion of the overall internet.

In our conversation, we touched on the relative importance of different aspects of software quality, standards for measuring quality, and the importance of a good architecture.

What follows is an edited transcript of our conversation with Curtis.

InformationWeek: We were in a conference today talking about the industrial IoT and how the quality of the software rests on three priorities, or pillars: Safety, security, and resilience. Do you place these three into any sort of hierarchy?

Bill Curtis: I'd certainly say safety first. I'd rather be alive than worry about whether my credit card got stolen, so safety above the other two. Resilience is important because you want to make sure you can recover things and they won't go down.

On the other hand, we're seeing -- even before we get into the industrial Internet of Things -- $100 million hacks on some of the security breaches. You're thinking bits or bytes: no, it's dollars or euros. So, once we make sure it's safe, we want to make sure we're not going to see some sort of horrible breach.

InformationWeek: When it comes to commercial systems, security has been a priority for a while, but for the longest time designers had the attitude that no one would want to hack industrial systems. Is the industrial side playing catch-up when it comes to security?

Curtis: A little bit. There are two issues there. One, they weren't as exposed to the internet. They had some exposure, but not like a bank had. They didn't have thousands of cash machines out there, they didn't have anything like online banking. 

It's really the emergence of the larger interconnectivity among the industrial suppliers.

When you look at the supply chain for some of these things, it's huge -- so it's not just me. It's integrating software from 5, 10, or 100 suppliers into the thing. We're going to have our systems linked up, sharing information and designs. There's tremendous exposure when someone breaks into one of these systems and starts stealing things.

InformationWeek: For the longest time, industrial systems weren't as exposed as commercial systems. When it comes to industrial systems, there's the attitude that "If it's not broke don't fix it." Do you see companies bolting on connectivity? Are they having to bolt on security as well? Or, are they doing rip-and-replace, where they're installing systems that have security built in?

Curtis: It's a combination of both. It's not that they haven't been exposed in the past. Lord knows how much industrial espionage has gone on.

But it's more exposed now, and it's just like the retail world, where the fact is they have old systems, and they're not going to be able to replace them. So they're going to have to do what they can to go in and harden them.

There may be some that are just so badly written that they'll go in and rip and replace. But in most cases, they're not going to have the time, or the luxury, or the resources to go in and replace everything.

InformationWeek: We keep comparing industrial systems to commercial systems. In the commercial world, there are external enforcers of security. Do any external regulations exist for the industrial side of things? Should they?

Curtis: You do have, for example, the FAA going in and regulating wherever human lives are at stake in flight systems. You have the FDA looking at medical devices. So, you do have regulators looking at industrial systems that have software embedded inside them.

You do have OSHA looking at safety issues, so you do have regulators there. But they haven't really started looking at what happens when you connect all these systems together. The existing regulators will have to start thinking more broadly about what their issues are.

[DevOps and Agile aren't synonymous. It pays to know the difference. Read Agile vs. DevOps: 10 Ways They're Different.]

I know the NIST is thinking about this. In a couple of weeks I'll be up there in Gaithersburg at a workshop. They're bringing a bunch of us together to talk about how we can measure security across all kinds of systems.

There's a huge focus now in the administration on how we can provide cyber-security for the United States, and that's all the way from our banking systems to the electrical grid.

InformationWeek: I'd like to poke at the last answer a little. Have we hit the point where there are any meaningful standards someone could turn to?

Curtis: In terms of software, yeah, the [Object Management Group] is a collection of companies that are very much worried about this. There are a number of standards. The one I'm involved with is the Consortium for IT Software Quality, which is trying to build standards for measuring the "-ilities" of software -- the quality characteristics for software.

(Image: alengo/iStockphoto)

We've got standards for reliability, security, performance efficiency, and maintainability. We focused initially on more IT-based systems, but we just had a new company join the consortium, Synopsys, which focuses heavily on the real-time embedded systems space -- so we'll be revising all these metrics now to focus on embedded software as well.

So we'll cover both commercial and embedded. Whether industrial or commercial, the fact is, you're integrating embedded control machines with IT systems that have the data that drives some of what you want to do.

What we're seeing now is the beginning of the demand to have the software certified. Remember, though, that software is only certified until the first patch. You're not going to be perfect, but you can show that you've taken due diligence to make sure that the software comes up to quality standards for safety, for security, for performance efficiency.

InformationWeek: When you look at software for IT versus software for embedded systems, are they two different creatures entirely, or can you take a lot of the standards for IT software and apply them to embedded systems?

Curtis: The way we've built these standards is that they're executed with static analysis, and we're looking for violations of good architectural and coding practice. For security, we're looking for things like cross-site scripting, buffer overflowing, SQL injection -- and it's simply looking for those and counting them up.

We're only looking for severe violations, the things you know you have to fix, so it's only a subset of the total violations. The questions are: Did they have a reasonable process in place for developing software, [and] did they have talented people in developing? Those would be the same questions you would ask whether you're looking at IT software or embedded systems software. 

The one difference between the two is you more often have people with engineering training, with computer science training, building the software for embedded systems. There was a survey recently that said somewhere in the neighborhood of 40% of all Java programmers are self-trained. That's horrifying. Nobody is training them in some of the well-known problems you've got to avoid.

In either case, you want to make sure they have a disciplined process and disciplined management that doesn't give them crazy schedules they can't possibly achieve and all of those kinds of issues.

InformationWeek: Given the speed with which the industry is moving, I've been astounded at how rapidly large companies are coming into the industrial IoT space. Do you think there is going to be significantly more guidance to people trying to do the right thing in the next 24 months, or do you think real guidance is a lot farther in the distance?

Curtis: There's a lot there that will help them. If you need help with process, you can go look at process standards. If you need to understand the quality issue, there's a lot of training on safety with critical software, how to write safety-critical [software], secure software training coming out of the Computer Emergency Response Team. There's a lot of information available.

You have to train people. The critical thing is, with the people who are going to be creating these critical systems, you have to make sure they've got the right training, that you've got senior people there who can mentor them on some of these issues, and that you have managers who have engineering backgrounds.

You need managers who understand both the technical and the business issues, so they understand what the uncertainties are and how to manage those.

That combination of skills in management is going to be critical. The standards are coming out. Some of them are already available. There's a lot of training and knowledge becoming available from lots of places.

The information is there, it just has to be organized, and managed, and trained at the company level.