Reimagining the CIA Triad Confidentiality Standards for Greater Security

Originally published by New Context.

Today, speed to market is a vital factor for organizations. Many have chosen to adopt DevOps principles because the process accelerates product development. However, this acceleration is a culture shift. When it’s not treated as such, there is a risk that rapid, unregulated change will result in inadvertently shipping bugs of all kinds, including security vulnerabilities. The only solution is equally rapid, robust security planning routed in both traditional methods and intelligent updates.

A return to the principles from the CIA Triad—confidentiality, integrity, and access—is necessary. This model treats security as a holistic part of the process. Confidentiality is built in from the very beginning. Some modernization through the distributed, immutable, and ephemeral (DIE) model improves this process even more. When focusing on the CIA triad’s confidentiality component, an approach routed in DevSecOps principles that incorporates end-to-end security through proven methods is best.

Reviewing the CIA Triad’s Confidentiality Standards

The CIA Triad is an established model that focuses on “pets” in a system. These pets are supported by a carefully managed infrastructure. They’re given unique names, and treated when damaged. They’re the opposite of cattle—the systems that don’t require special treatment and are disposed of when damaged or unnecessary.

The CIA Triad’s confidential portion centers on protecting sensitive resources from unauthorized views. It’s comprised of two subclasses: authentication and authorization:

Under this segment, methods used run the gamut from old school passwords to complex biometric identification programs. The more sensitive the information, the higher the authentication and authorization level.

Here, an enterprise ensures their state’s security by focusing on uptime and backups. However, in a CIA-only approach, the maintenance cost of the systems managing that state is so high that they require constant vigilance. The DIE approach significantly lowers that maintenance burden by loosening the coupling between said systems and their state so that the systems are easily replaced at will.. Traditional methods of protecting state under the CIA model include:

• Encryption: Converting data to code both as it travels (encryption in transit) or as it sits in storage (encryption at rest) provides a layer of protection even if bad actors make it past access control and other protocols. Even if they capture the data, they can’t use it.
• Identity access management (IAM): IAM isn’t a single tool. It’s a suite of them that manage both who can access the system and why they can. It incorporates password applications, monitoring programs, provisioning software, and reporting protocol systems, among others.
• Multifactor authentication (MFA): MFA takes password management a step further by increasing authentication steps. Users may provide an initial password and then be prompted to also verify something by possession (aka something they have, like an email), inherence (something they are, like a fingerprint), or knowledge (like the answer to a security question only they could know).

The CIA model is still relevant for security, but modern needs have changed it a bit. In many instances, organizations deal with different programs and platforms, making authentication and authorization a more significant challenge. However, the distributed, immutable, and ephemeral model can help close these gaps.

Expanding on the CIA’s Model with DIE

The DIE model won’t replace the CIA triad. Instead, it’s a layer that works on top of it. While the CIA triad addresses the pets in a system, the DIE model handles the cattle. Specifically, it centers on the infrastructure and applications. The two do the same thing—loosen the coupling between the systems processing data, and the data itself.

The infrastructure of a program is possibly the most disposable because using the right processes, it can be recreated using a repeatable script or code, aka infrastructure as code. In the event of a breach, administrators can dump the code and rebuild everything from scratch. This may seem like it doesn’t fit with the CIA’s confidentiality component because, after all, the very things that must be confidential are pets. They are not disposable. However, the “ephemeral” part of DIE is a central component of ensuring confidentiality.

It’s best explained by the mapping completed by cybersecurity expert Sounil Yu, who connects the ephemeral of infrastructure to data confidentiality. In his strategy, he advises firms to “drive the value of assets closer to zero.”

In practical application, that means when an enterprise starts or uses any system, it will have internal state, whether it be databases, hardcoded data, or something else. That state must be offloaded to ensure the infrastructure that holds that data remains ephemeral. Administrators must remove the data and send it to a safer place, whether it be another database, secrets management, or all-inclusive programs like Vault by HashiCorp. Regardless of storage, it’s necessary to pull the state out of a system and send it to a safer place. It may feed the applications or programs, but it’s never a static part of them.

When it’s really broken down, InfoSec is risk management. When speed to market comes at the expense of confidentiality, enterprises stand to lose a lot more than they gain. Administrators must select a method of storage that requires deep authorization and authentication while keeping it separate from infrastructures that should be ephemeral.

Partnering with a Security Consultant to Tighten Your Confidentiality Standards

The key to controlling the CIA Triad’s confidentiality aspect is to maintain flexibility in a secure environment. Laying the DIE model on top of the CIA’s framework allows enterprises to separate their pets from cattle and focus their attention on invaluable systems. Such a strategy establishes a fundamental security level capable of supporting any DevSecOps program.