How to best introduce CIA (confidentiality integrity availability) security dimensions in risk management?

[Tasis]

In the domain of IT Security Risk Management, it is typical to model risks in a way that captures their impact on one - or more - of the 'classic' CIA (confidentiality integrity availability) security dimensions.

As a basic example, the general risk 'Theft' can compromise 'Confidentiality' as well as 'Availability' of a given Entity, so we could then expect to have two risks (Theft compromising Confidentiality, Theft compromising Availability) each having potentially different inherent risk values (as the impact of Confidentiality loss vs. Availability loss can be different for the organisation).

Typically we would consider CIA dimensions for two major use cases: a) computing the inherent / residual risk values per applicable CIA dimension (based on the corresponding CIA impact value as explained above), b) roll-up the risk values from individual risks at the CIA level (i.e. show the overall (max) risk value related to Confidentiality).

ServiceNow IRM seems to lack this type of modelling capability in Risk Statements (i.e. a property to associate them with one or more CIA dimensions).

What could be a 'best practice' to introduce the CIA concept in risk modelling? A first idea that comes to mind would be to use Risk Hierarchies, and to use 'Loss of Confidentiality', 'Loss of Integrity', 'Loss of Availability' as the 1st level Risk Statements, and then have related Risk Statements at 2nd level. The issue with this approach is that Risk Statements compromising more than one CIA dimension would need to be repeated, e.g. 'Theft' would need to created twice as a Risk Statement, 'Theft compromising Confidentiality' (under 'Loss of Confidentiality) and as 'Theft compromising Availability' (under 'Loss of Availability). This has the risk of creating a lot of redundancy in such a Risk Framework, and it reduces our capability to look at 'Theft' as a single risk.

Another approach could be to customise IRM and extend Risk Statements / Risks to include a link to one or more CIA dimensions. The risk here is that we would need to customise extensively all the ootb features (risk calculation, risk roll-ups, etc.) to satisfy our use cases.

Has anyone come across this issue? Is there a best practice that would be inline with the ServiceNow IRM vision?

@Phil Swann I follow extensively your very good advice on such topics, any insight you may have would be much appreciated.

[Community Alums]

Tasis and Phil:
Good question - very timely.  And your application of CIA is useful and spot on.  I am currently working on developing a program for Automating Control Assessments, (working to advance the Maturity that ServiceNow maps out in SO many of their GRC powerpoints), and have been reading up on NIST guidance in this area.

NISTIR 8011, Volume 1: Automation Support for Security Control Assessments - Volume 1: Overview, and NIST 800-53B Control Baselines for Systems and Organizations, address your thoughts, and the use of CIA in Risk and Security Controls very well.  

Specifically in 800-53B (you and Phil probably already knew this - but the definition was new to me): In section 2.2 Security Control Baselines, (which also discusses Security Categorization - which I found very beneficial in Automation), they define Low, Medium and High ratings in these terms, (underlining is my emphasis):

Information security programs are responsible for protecting information and information systems...in order to provide confidentiality, integrity, and availability.

The control baselines selected for systems are commensurate with the potential adverse impact on organizational operations, organizational assets, individuals, other organizations, or the Nation if there is a loss of confidentiality, integrity, or availability. [FIPS 199] requires organizations to categorize systems as low-impact, moderate-impact, or high-impact for the stated security objectives of confidentiality, integrity, and availability.

Thus a low-impact system is defined as a system in which all three of the security objectives are low. A moderate-impact system is a system in which at least one of the security objectives is moderate and no security objective is high. Finally, a high-impact system is a system in which at least one security objective is high.

Hope this helps.

Mike Cook

[Nick T]

For the same question, I'm considering creating Group Factors for Confidentiality, Integrity and Availability that each include contains Manual Factors, such as VH, H, M, L, VL.

Would this be a way of making sure CIA is considered?

[Community Alums]

Sounds like an incredible amount of effort.  Don't know whether you're using ISO27002, or NIST 800-53, but each has over a 1,000 controls each.

Not as detailed as you're considering, but NIST 800-53B (Chapter 3 - Control Baselines), has all their Controls listed by Family, both Base and Enhancements, with an overall indicator of Low, Medium, and High.  But the indicator is an aggregate of CIA, not broken out individually by C, I, and A.

[Sebastien Fix1]

Not all 1000s controls related to each risks. You will need to map the relevant controls for each risks anyway, so this is not an issue as such. 

@Nick Tegg This is the way I would go tbh, you only need to setup one RAM to capture the information - especially since SD where one RAM can be used across multiple entity classes. 

If you want some automation you can do it on the controls side using (automated/scripted) indicators and now metrics. Without going IRM Enterprise, you do not have access to automated factors, so using risk indicators seem more limited that control indicators from my point of view. (Control indicators would at least impact the compliance score which can be aggregated while risk indicators would only be there as a reference to the risk record)