If it isn’t secure, then it doesn’t work as intended; and if it doesn’t work as intended, then it has a quality problem.

Therefore, your service or product must have great security in it before you can say it has good quality.

Consider the following aspects of quality that you might be familiar with:

  • Usability
  • Performance
  • Scalability
  • Reliability

Now, try to imagine any kind of software system that is used in production, such as an online banking system, or an electronic health records system. Then, think of how a defect in each of the above attributes of the system could directly affect people.

  • If the system was not usable, then anyone trying to access the system may be delayed or prevented from completing a transaction.
  • If the system did not perform well, with reasonable response times, a similar result could occur.
  • If the system was not scalable, then during peak times, performance would lag, or the system might even crash. This would prevent anyone trying to access the system from successfully completing their transactions.
  • If the system was not reliable, then it may not be available at times, or may crash and prevent people from completing transactions.

In all of the above cases, the users attempting to access the system are directly affected. In addition, the system owner may experience financial losses because of the failed transactions.

These scenarios are the typical “worst-case” problems traditionally considered by software system designers.

But if the system’s security is defective - i.e. it has a design flaw that exposes sensitive data - who is directly affected? If a hacker breaks into a network and steals the credit card information or userids and passwords of ALL registered users, then ALL registered users are affected, not just those attempting to access the system at the time that it failed. These individuals may not even be customers. Their health or financial records may have been transferred for processing by third party organizations. This kind of failure is not the same as a momentary failure of transaction processing. It can be much worse.

So, if designers treat a potential system crash as the most critical type of quality problem to be avoided, how should they be treating potential security defects that could affect every individual whose records are handled by the system, whether they are customers, patients or customers‘ patients?

In today’s world, where information travels through many interoperating systems, the impact of security defects, or vulnerabilities, on all stakeholders must be considered during system design.
Not all security defects will necessarily affect all whose information is in the system, but the potential impacts of design failures in the area of security are at least as important - or more important - than the other, traditional software quality factors that have been used for the past 20 years.

So, when a business manager gives a system development team a set of functional requirements and says, “Oh, by the way, it has to be reliable, usable and have good response times,” they may not be thinking about security as a quality requirement - but they really should be. Otherwise, in the real worst-case scenario, they may find themselves wishing it was “just a system crash”.