From CIA to #CIA

The latest expose (thanks, Wall Street Journal) of the 500,000 accounts of Google+ users and the silence that Google maintained, despite having discovered and patched the bug back in March, triggered a thought process that culminated in this article.

One of the oft used acronyms when it comes to describing cybersecurity is CIA, which stands for ConfidentialityIntegrity and Availability. It was developed as a security framework to provide a universal standard for evaluating and implementing cybersecurity regardless of the underlying hardware, software or organization. And it has served its purpose well – until recently. But before we go any further, let’s define the definitions of these terms.


As the term suggests, this is about protecting your most sensitive assets. This could be data, machines or software. Some of the commonly used means of confidentiality enforcement include traditional file access permissions, firewall rules, encryption, administrative permissions, etc.


This is typically tied to data integrity. That no unauthorized machine or individual has been able to modify the data at rest or in motion. And the integrity could be enforced by not allowing any modifications at all or in some cases, the ability to roll back to a known good state after the breach of integrity has been detected.


This is to ensure that all systems and capabilities are available and reachable at all times. The security aspect would be to ensure rollback in case of a configuration error, preventing massive Denial of Service attack, network redundancy, rolling software upgrades, etc.

So where am I going with this? It’s time to move from CIA to #CIA. What is #CIA? It’s the new dissertation of #Confidentiality, #Integrity and #Availability for today’s brave new world.


In the world of IoT, AI, APIs and cloud – this confidentiality takes on a whole new meaning. While the original goals of confidentiality are still relevant, today it extends into truly anonymizing data collected from the billions of sensors that exist on our phones, TVs, smart refrigerators, connected toothbrushes (yes, they exist) so there is no digital trail back to the source so sneaky, targeted ads cannot be pinpointed with eerie precision. It involves maintaining user confidentiality and respecting privacy choices users have made, even when sharing customer data with third-party applications. And it extends to ensuring this confidentiality can still be maintained even after crossing the third-party app border crossing. Yes, in an API-happy world, data brokering is to be expected but without #C implemented properly, this will result in the Facebook+Cambridge Analytica-like fiasco for any organization.


The principles of data integrity still apply today but integrity takes on a whole new meaning in this age. It is doing the right thing always – especially when things go wrong. And that requires active debate, codification and scenario planning of very difficult “what if” situations. It is about respecting user privacy, creating EULA (end user licensing agreements) that users can actually comprehend easily, and when it comes time standing up and confessing when you failed and what the impact of that failure to the customers. In the Google+ example, the decision to not disclose this vulnerability and data expose came from two groups. The Google lawyers who felt that disclosing the incident would likely trigger “immediate regulatory interest” and invite comparisons to Facebook’s leak of user information to data firm Cambridge Analytica” so lie low. And from the Privacy & Data Protection Office who apparently looked at the type of data involved and determined that (1) they could not accurately identify the users to inform, (2) there was no evidence of misuse, and (3) there were no actions a developer or user could take in response. And so, they decided to stay quiet. That is #Integrity – or actually the lack of it.


Much like #C and #I, #A is also is defined on a much larger canvas today. In the SaaS (software as a service) world, where much of the underlying infrastructure is reliant on third party clouds like AWS and Google, the vendor needs to assume the responsibility of not just his or her app but the entire infrastructure even if they don’t own it. But unfortunately, that is the exception. In fact, if you look at the FAQ or Privacy and Security pages of many SaaS companies, you typically see verbiage that sounds like “we run on the #AWS public cloud, so while we make every effort to make our application resilient and available, the underlying infrastructure is #AWS responsibility ….” #NotAcceptable. Yes, you cannot have the legal team define the weasel exit here. Yes, most folks understand the reliance on third-party cloud infrastructure. But, taking responsibility for your SaaS availability and offering compensation and assuming moral responsibility in the event of any downtime – that will win you customers and loyalty.

So that, in a nutshell, is #CIA for today’s world. Every business, vendor or service organization needs to pay heed to this expanded definition so they can not only survive but thrive securely.

This article originally appeared on