Anyone who has any familiarity with the field of information security has encountered the abbreviation “CIA”, which is short for “Confidentiality, Integrity and Availability.” These are often put forward as the essential drivers behind efforts to secure information systems and the data they contain.
When applying information security principles and practices to industrial systems security, we’ve heard debates about whether these drivers apply equally for both domains. In fact, while confidentiality may be the foremost imperative for information systems, there is a common argument that the order should be reversed for industrial systems, placing availability as the highest imperative. Others have stated just as emphatically that the primary concern must be with the overall integrity of the system, since without integrity, it is impossible to ensure either confidentiality or availability.
But does the relative importance of these attributes really matter? Is it even possible to address any of the three independently? Perhaps a relative ranking is only important in rare cases where the designer or operator of a system is faced with the task of choosing one over the other. Are such scenarios realistic?
Perhaps the most common scenario cited is where the security software blocks access to a system after repeated failed attempts at access. Such “lock-out” methods are usually justified on the basis of protecting the system and its data from unauthorized and potentially malicious access. Of course, one can imagine scenarios in which this may not be the best response. Do we really want the operator of a hazardous chemical process to lose the access and ability to intervene in a high-stress moment because he or she “fat fingered” their password too many times?
What about the operation of piloting a commercial aircraft? After stepping out of the cockpit, should a pilot have to reauthenticate before taking back control of the airplane? Clearly this is not the case, but does it really demonstrate the superior importance of availability over confidentiality?
There is little doubt that a reasonably creative person could come up with all manner of problematic or ambiguous scenarios that would challenge or event prevent a simple and conventional response. But why bother? Do debates about theoretical or abstract scenarios really help? Probably not.
The interests of those who design and operate complex systems are better served if everyone simply takes the time to carefully consider what each of the essential attributes really mean. For example, in the case of confidentiality, it only means something if you have defined specifically what information is to be protected, at what classification level, for what purpose, and from what class of people.
Integrity also needs further definition. Of course, there are all sorts of dictionary definitions for the word, but what does it mean in practical terms for a complex system to demonstrate operational integrity? Such a description must also consider performance under a wide range of conditions. A full analysis can quickly become quite complex.
Perhaps the easiest attribute to address is availability, since it can be measured in unambiguous terms, such as percentage of uptime, mean time between failure (MTBF) and mean time to repair (MTTR). There are also several design choices available to provide high availability, ranging from higher quality components to various levels of redundancy. Industrial system designers are familiar with all of these.
So, what is the bottom line? Balancing the various imperatives associated with the security of a complex system can (and often is) a very complicated exercise that must be an integral part of system design, operation and maintenance (i.e., across the lifecycle). It cannot be reduced to simple either/or alternatives.
Engineering and security experts know how to perform the required analyses. While it is perfectly reasonable – even expected – to challenge them about how such analyses are conducted and how conclusions are drawn, let’s not fool ourselves by reducing it to a simple question of alternatives between “CIA” and “IAC.”
About ARC Advisory Group (www.arcweb.com): Founded in 1986, ARC Advisory Group is a Boston based leading technology research and advisory firm for industry and infrastructure.
For further information or to provide feedback on this article, please firstname.lastname@example.org
About the Author:
Eric provides advisory and consulting services to ARC analysts and clients in all aspects of operations and project management. Eric has over 35 years of experience in the development, delivery, management, and support of operations information technology solutions in the process industries. During his career his assignments and responsibilities have included process automation systems development, communications network design, functional and technical architecture design, and technology lifecycle management. He recently retired as an Operations IT Consulting Engineer with the Dow Chemical Company.