CIA, the mnemonic for Confidentiality, Integrity and Availability, is often called the foundation, the heart, the ‘holy’ triad of information security. It is preached and practiced much like a religion. Sacred. Question its usefulness and you get angry looks. Some have said that one other item should be added to CIA: Non-repudiation or accountability. So why not use STRIDE as a mnemonic? It sounds nice too and it is also an acronym: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service, Elevation of privilege. STRIDE (the threat model used in Microsoft‘s SDL) is great for analyzing processes across trust boundaries. It would be well-suited for today’s web of connected devices and apps.
For me CIA is overrated and taken much too seriously. It is not the foundation nor the definition of information security. Also the Deming cycle PDCA (Plan-Do-Check-Act) is not the definition or the foundation of Quality management. When I see someone use CIA, I often just shrug. I get squeaky when it is applied blindly like some holy dogma. But in this post I want to dig a little deeper and explain why I believe CIA points to an outdated and inadequate approach to security analysis.
Data-centric versus service-oriented
To understand why the CIA triad is almost ‘holy’ it is good to go back to what some consider the bible of information security: the ISO 27001 standard. It defines information security as CIA of data. The standard starts by saying that information security is about protecting “anything of value”. But then much of it focuses entirely on the data. Many information security professionals took the cue and are repeating the mantra: “follow the data”, “it’s all about the data”. Do a data-classification before anything else and go from there.
The classic example where this does not work: an online banking system, online shopping cart, or an online booking system. To view your transactions a password is required and to make a new transaction 2-factor authentication is required. In this example the only sensitive data involved is the the account statement and the personal information about the customer. CIA gets you nowhere.
Yet many experts stubbornly start with data-classification and CIA. There is a hilarious video about this by Vicente Aceituno Canal https://www.youtube.com/watch?v=V69QOcyLYBA
What is the underlying problem? A data-centric approach was all right in the 90s. Most business applications were just a GUI around a couple of database tables or a set of (stored) SQL queries or stored procedures. The rest of the IT universe was data-storage; files and folders. The users internal to an organization. In that time CIA went a long way. But since then IT changed: In the 2000s service-oriented IT architectures became best practice. A system offers several services each with a different ACL and different SLA. Data, databases and file systems are an after-thought rather than the defining component. IT systems offer interfaces, interacting with different data sets across the organization. And we are facing real attacks now. IT security is no longer a paper-based compliance exercise. Each interface, each service needs to be analyzed separately. With service-oriented architectures data-classification and CIA falls short and is almost useless.
REST, ACLs and SLAs
To find a better approach let’s look at the IT we are trying to secure, and figure out the best approach. MVC (a software design pattern) and REST (an architecture style) have been best practice for a decade. Take a specific example of an MVC application in a REST-full service-oriented architecture. In a REST-full architecture a system is defined in terms of abstract high-level business objects. Each instance of an object gets a unique address (typically a URI) and exposes an interface of four operations: Create, Read, Update, Delete (CRUD). Take for example the online e-banking system. Let’s look at the security of each operation and who can call it:
- Create – ACL: Customer – 2-factor, and nobody else.
- Read – ACL: Customer – 1-factor, and nobody else.
- Update – nobody
- Delete – nobody
That was easy and clear. So instead of trying to look at the data, we look at each system interface and each function. Data is involved of course, in the transactions, but the security analysis follows the interface, not the data.
On the surface it may seem that REST goes back to the data-centric view. CRUD denotes the 4 basic functions of persistent data-storage. But it is good to keep in mind that REST does not deal with data directly but with abstract ‘business’ objects. REST uses an abstraction layer for modeling the ‘business’ processes supported by the system. So for instance if you implement an airline flight booking system, the high-level business object could be a flight booking. When a new flight booking is created a range of different types of data is involved: the flight data, passenger name, credit card data, meal preference. Data is not exposed directly.
Liveness and safety
If we drop the CIA triangle, the mnemonic, what can we use instead. Personally I use something simple from the field of security/crypto protocol analysis. In protocol analysis security properties are divided in two: liveness and safety. Liveness means “something good eventually happens”, and safety means “nothing bad ever happens”. It is the yin and the yang of security. Under liveness (the yang, the white) you whitelist what is allowed (the access control list), the functional specifications of the system. Under liveness you would also look at things like continuity, the SLA of a process. Under safety (the yin, the black) you look at things that you don’t want to happen. It is tricky as always. In theory it is easy to say “and nothing else should happen”, but in practice systems are complex and there are a lot of things which have not been explicitly allowed, but are still unsafe. This is where threat modeling comes in: the OWASP top ten list, STRIDE, attack trees, a brainstorm.
It is time to leave the mantra of data-classification and CIA behind and start looking at the services and processes. IT has been service-oriented for a decade now. We can not pretend this did not happen and stick to a data-centric view. A practical example of a more modern approach is STRIDE. And if STRIDE does not convince you, an even more elegant approach is to look at liveness and safety, for each operation. Duality instead of the triangle. Out with CIA.