CIA Security Testing

A key concept in the IT security space is the mnemonic “CIA” of the Confidentiality, Integrity, and Availability of a system [https://en.wikipedia.org/wiki/CIA_triad] – not the other CIA… The mnemonic helps identify risks to the system in each theme and helps organizations construct “controls” or requirements around mitigating those risks.

• Confidentiality: That things are not shared to unauthorized people or systems
• Integrity: That things are not modified, and that modifications are credible
• Availability: That the system is available when needed, and can recover from being unavailable.

Availability is not to be interchanged with Accessibility, which is a different system quality attribute. And there are at least 100 quality attributes. While we usually deal with more functional quality attributes or service response attributes, security can be an additional track for the experienced quality engineer.

Every organization has a security responsible, and in Europe there’s a law for large companies to have a CISO – Chief Information Security Officer, who is in charge of your company’s overall quality manual and information procedures. Along with the legal team the CISO is usually interested in that the internal systems are indeed confidential, have high integrity and are available when needed. If C, I and A is not considered the whole company as such are hindered in running (effectively).

If your security team prefers Center for Internet Security’s 18 Critical Security Controls. – check out: https://www.o2sn.dk/2025/04/23/testing-corporate-cis18-security/

The CEO has an active interest in being in control of C,I and A.

Hence there is a clear business case for anything related to company security. Can we test for yet – yes we can!

Confidentiality

Confidentiality is a well-known system property and is recognized in many consumer applications and IT systems in general. It’s part about authorizations (to users and other systems) and parts about that private information is not shared. This goes for integrations too and is the reason for many companies having a zero-trust IT infrastructure and require certificates on the end-points. If your system holds personal identifiable data a system requirement could be that data is encrypted both in the database and when transported. Confidentiality concerns is what is behind your company monitoring the firewalls, both for what comes in – but also for what comes out. Is personal data or company secrets being shared to the public, to random LLM-chatbots or similarly leaked?

Authorizations are a classic testing activity. Almost all software testing vendors build their demo on “let’s test a login page” also the classic testing examples of access controls. Given a system with role-based access controls (RBAC to the CISO), we can test all the combinations of “read, update and delete” and to test with all the roles. Especially those with limited access.

With Confidentiality we can imagine many things to test for and challenge. Should we test everything – even those that are standard system features directly of of the solution box. I mean, should we challenge the encryption software – where do we stop? My approach would be to have the discussion using a Wardley Map – as part of the the testing strategy. Investigate what is most directly related to your stakeholder and what is not yet a commodity and apply your testing there. See any of these posts for more: https://www.o2sn.dk/tag/wardley/

Integrity

Integrity is one of the reasons behind a formal ticketing system and most ITIL procedures (an IT operations framework): All changes to production must have a ticket and that ticket must be approved. Often Integrity focus on data accuracy and completeness – over the whole life span on the data. From data creation to data retention and disposal.

Approaches to test system integrity could look into:

• human and social engineering aspects: Can only one person transfer company funds – or is there a two step mechanism?
• processes: if data is to be deleted after use, who oversees that the data is deleted?
• credibility and reliability: does the system always give the same answer over time?
• accuracy: does the system follow a time protocol , how consistent are the calculation of monetary values?

Testing for system integrity is a relevant aspect in many IT systems and solutions. Especially those that handle payments, monetary transactions and personal data. You will surely loose customers if your system integrity is not in place. Integrity is what many vibe-coded and temporary solutions lack. That they don’t hallucinate.

Availability

Testing for system availability is often framed in the non-functional system requirements – Up Times, Service Level Objectives and Recovery procedures. Each of these system properties are a field on their own. System availability risks could also consider all things around the solution, like contingency planning.

A new angle to consider these days is data sovereignty. A topic that comes up a lot in main-land Europe and Canada and challenges not only where data resides – but under which law and jurisdiction. Your system is not available of a hostile government denies access to your data because it’s hosted cheap in that government’s jurisdiction.

More on testing general system availability in the posts below: