The “CIA Triad” is undoubtedly familiar to those of us working in information security and auditing.  Standing for “Confidentiality, Integrity and Availability,” – the three original goals of information security that still stand today – the CIA Triad is what forms the foundation for what we all do.  Ensuring the confidentiality, integrity and availability of information is critical when it comes to the operation of a business. As auditors, nearly everything we do goes towards making sure those three goals are being met.

In short, information must only be accessible by those granted advance permission . . . those with the “need to know.”  That information must also be whole and correct, and it must be available when it is needed.   None of these three goals can be missed, for a business to be able to function properly.  Ensuring these goals are met is an ongoing process that is never truly complete.

As time has gone by and technology evolves, many people in our field have brought up a fourth goal, that of control.  As more businesses move to cloud-based services and infrastructure who is really in control of information? This is a very important question we must ask.  In days gone by this was a simple question: information is stored on-site, or at a small number of off-site datacenters that were vetted properly.

Today, your information could be stored at any one of dozens or even hundreds of third-party facilities. To complicate matters even further those third parties may be entrusting your information to their own subservice providers.  Each of these organizations will have their own staff with their own levels of access to this information. Which will, of course, add a new layer of availability risk. Basically, there are now many more links in the chain, so to speak.  Our loss of control has extended beyond “who hosts the data” and “how is that data secured” into other aspects of technology governance.

Take recent findings in audits where Clients didn’t realize they had AI enabled in one of their applications.  For example, CRMs, Zoom, etc. just rolled it out, default on.

Shadow AI is alive and well, and then when you look into it your first step needs to be, “is this even AI?”  And it needs to happen quick.  Can we schedule it?

No.  We have lost that control.

All of this means that vendor due diligence is now more important, and more complex, than ever.  Of course, especially if you are a bank, you are probably already implementing several controls to address this loss of control.  Termination plans, local data backups, and just recognizing the risk may be implied, if not directly required, in guidance.

And those in banking have been dealing with the chicken/egg problem arising out of what the SSAE-18 calls “subservice providers.”  Not only do you need to do your homework on the vendor you’re directly contracting with, you need to know who that vendor is using to provide their services.  We’ve long ago helped make this effective by focusing on expected controls, as shown in our movie, “How to Review a SOC-1 or Two.”

But as you dig a little deeper and you will find that Microsoft Azure, Amazon Web Services and a small handful of other cloud services providers are powering the vast majority of the internet, including many of your cloud services.

Some of us have been slow to adopt cloud services.  They may be late majority adopters, maybe even laggards.  But they balance their Cloud FOMO with the satisfaction of control.  You ask somebody still hosting their own core on what most of us would consider “an old-fashioned mainframe” and they will answer, “control.”

Meanwhile, we have lost control of our applications.  Long gone, the days when you would decide when to update your application.  Thanks to cloud computing, we no longer implement the tactical aspects of vulnerability management for many of our applications.  A great benefit of cloud computing is that patch management is handled for us.  But in this benefit we have sacrificed control over application changes, and at any time we can be asked to pause our work while the application updates.  Worse, each time we log into an application, we find ourselves learning a new application.  This creates operational and security risk, and just makes our jobs harder.

So with all that as a backdrop, Dan is now proposing that we change the metaphorical diagram we use to present the three goals of information security.  Where we used to refer to the CIA Triad, a triangle, maybe we should say CIAC Pyramid (but write it as C²IA Pyramid).  We need a pyramid to represent that second C, and the increased complexity of losing control seems three-dimensional.

Ultimately it’s those “behind-the-scenes players” that may be in control of your information and applications, regardless of the company you are contracted with directly.  Is the risk of ceding control of your information to these organizations worth it?  In many cases it may be, and as more and more services transition to the cloud it may be unavoidable. However, that does not free us of the obligations we have to maintaining the confidentiality, integrity and availability of the information entrusted to us.

So, Control is a new goal.  The CIA Triad is a now CIAC Pyramid (or C²IA . . . who knows what the actual name will be once the marketing and accounting firms adopt it).

Having fully introduced the goal, let’s not just end the article without at least addressing the notion of “achieving” the goal. As is always the case for information security goals, let’s lower the risk of NOT fully achieving the goal. Some would say, when it comes to control, the horses are already out of the barn. And the effort to corral even the slowest of them back into barn raises more strategic risk than it could fix.

We get that.

We get it so much, let this article caution you to be careful that your controls don’t lead to a net zero benefit.

But we don’t say “there’s nothing you can do to stop a tornado,” when it comes to addressing the availability goal of the CIA Triad.  Sure, when it comes to the companies Dan calls “the Big Bells” we may have lost a lot of control.

Of some things.

Even with the Big Bells, there are controls we already apply.  We’re used to fixing Big Bell security holes.  The Big Bells became big in part because they took the risk of “bolting it on instead of building it in,” and then had the audacity called, “make-your-customers-fix-your-problems.  (Can you say, patch Tuesday?)

But yes, in big picture ways, the Big Bells have trapped us.  Those who have droids are no longer going to be able to switch to an apple ecosystem, and vice versa.  If you’re using azure, you have lost as much control as you have gained functionality and risk mitigation.  There’s a trade-off and we’re going to have to live with decisions we made a decade ago.  We get that.

But we still control what we add to our “ecosystem,” and we still control which ecosystems we’ll be trapped in.  We also control the configuration of those applications.

Not all of the horses have left the barn, and some can be lassoed in, at least a bit.  And again, just because we can’t stop a flood, doesn’t mean we shouldn’t develop mitigating REACTIVE controls.

And hey, as a vendor of a cloud SIEM architecture, we realize there are certain controls you should put in place to protect you from the control you may lose if you go “all-in” with our virtual appliance.  First, you should have assurances about pricing, and the easiest way to get them is a “no questions asked” cancellation-clause in your agreement.  That actually solves a lot of problems.  Second, you want to know how data destruction works and . . . heck, we can write a whole new article detailing what can be done.

But we also know there are ways you can check for our controls, instead of taking our word for it.  In fact, that’s why we have the movie, “Testing Your SIEM” on our blog. (Editor’s note: look for a refresh soon!)

But beyond what some vendors may consider draconian contract language, there are other controls you can implement to give yourself more control.  Controls over control.

These range from quickly learning backup systems, having the configuration audited and then audited again, termination agreements, termination plans, breach monitoring, etc.

“Control controls,” Dan jokes.  Then he adds, “meta-controls.”

And Dan and Matt are thinking about . . . for our next Jolley-Hadaway article . . . we will go further into detail on the “Top Ten Meta Controls to Help You Get Control Over Control.”   But you have to ask for it . . . and tell us how YOU are controlling control!

But for now, let’s at least list them:

1. Control Assessment
   1. Rate vendors and assets by level of control
   2. Recognize (and inventory) what you DO have control over
2. Let Go, the Banana” – you don’t have to use some technologies.
3. Data Format Agreement and Testing
4. Shadow AI Configuration Check
5. “Stopping the Slam” (i.e. disabling One-Drive)
6. Check Privacy and User Agreements
7. Bolt Security On (embrace it, little bell)
8. Data Destruction
9. Reference Checks
10. Network Monitoring (access, use, availability, integrity)

Stay tuned for more blogging about the above “Meta Controls.”

This has been a Jolley | Hadaway effort.  A Jolley | Hadaway article usually results when both Matt and Dan are ranting about the same technology problem, such as the lack of control we have over data and applications.