Cloud Controls Matrix

Good day fellow participating professionals. Please allow me to ask your advice.

The example I use to illustrate my question is taken from the CCM v4 to IBM CFFS controls mapping exercise, but let's not limit the discussion to only the CCM to IBM CFFS mapping exercise. I am keen to hear what you think is the best way to approach any such scenario in current and future mappings regardless of the framework. I am cognizant that the mapping methodologies vary from time to time, and we might need to handle each initiative on a per-case basis.

The question at a high level:
If we map a single control from CCM to any target framework, and the target framework contains multiple controls that describe the same set of requirements and any of them can close the gap;
(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For example:
CCM Control 1 requirement: Stop the tap from leaking water.
Target framework control 1: Do not leave the tap open so it would not leak water.
Target framework control 2: Close the faucet.
Target framework control 3: The valve should be closed tight to not leak fluid.

Mapping CCM Control 1 to Target framework control 1 will be accurate and will close the gap.
a) Should CCM control 1 map to the Target framework controls 1,2 &3? or,
b) Should CCM control 1 map to the Target framework control 1, and because the gap is now closed ignore target framework controls 2 & 3?
c) Any other suggestions?

Real-world scenario using CCM to NIST mappings:
Please consider the following NIST controls - SA-3, SA-4(3), SA-8, and SA-4(2) – all listed below.
It appears to me that SA-3, SA-4(3), SA-8, and SA-4(2) all clearly describe the need for a well-defined SDLC.

Let's consider the requirement of a CCM v4 control such as AIS-04: 'Secure Application Design and Development' – 'Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization.'

If we want to map the CCM control (AIS-04) requirement to NIST 800-53-r5, it appears the NIST 800-53-r5 control SA-3 will be an accurate map, and it contains a sufficient degree of detail to completely close the gap. How should we handle the remaining NIST 800-53-r5 controls SA-4(3), SA-8, and SA-4(2)?

The NIST 800-53-r5 contains the following controls:
SA-3:
'The organization:
(a) Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;
(b) Defines and documents information security roles and responsibilities throughout the system development life cycle;
(c) Identifies individuals having information security roles and responsibilities; and
(d) Integrates the organizational information security risk management process into system development life cycle activities.
Supplemental Guidance: A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies.'

SA-4(3): 'The organization requires the developer of the information system, system component, or information system service to demonstrate the use of a system development life cycle that includes [Assignment: organization-defined state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].
Supplemental Guidance: Following a well-defined system development life cycle that includes state-of-the-practice software development methods, systems/security engineering methods, quality control processes, and testing, evaluation, and validation techniques helps to reduce the number and severity of latent errors within information systems, system components, and information system services. Reducing the number/severity of such errors reduces the number of vulnerabilities in those systems, components, and services.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-4(2): 'The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].
Supplemental Guidance: Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.'

Looking forward to your kind response.

Regards,
Johan Olivier

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------

I'll try to unpack this and answer all the questions best I can :)

First your specific questions as stated:

(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For (a) I recommend defining a conceptual vocabulary and articulate what you think each is trying to accomplish in those terms - it's less about whether you have the "right" answer and more how you can explain your methodology to someone else, at least that has been my audit experience.

For (b) we need to better define "gap": i) completely missing requirement ii) redundant/overlapping requirement, iii) ambiguous requirement that is easy to interpret multiple ways, iv) very precisely defined requirement,

I would argue your leaking water example above is an example of ii​ or possibly iii - a poorly defined set of requirements in the target framework that ought have been designed to be non-overlapping (MECE - mutually exclusive, collectively exhaustive). For this - I personally would map them all just for completeness sake and to not have to have the conversation repeatedly why something is not mapped.

Your NIST 800-53 example is an example of iv - the various items you cite are very different and non-overlapping:

SA-3 is about  attributes of a system development life cycle - b) the roles, c) the individuals, and d) the integration of risk management. SA-4(2) is about "different levels of detail in design and implementation documentation" - about the documentation artifacts that must be produced during the execution of a lifecycle. You'd be surprised how many enterprises have a lifecycle doc but no documentation artifacts from the various activities that are part of that lifecycle. For example I can hold a design review session - but do I document it? How? What diagrams are required? Do I do code reviews? How? What documentation is produced? etc. SA-4(2) is telling you to define what level of detail you plan to require.  That will be different for a social media company vs. military weapons system (I hope!)


These are all very different things than demonstrating "state-of-the-practice software development methods" for SA-4(3).  I can define a lifecycle for SA-3 that is waterfall or Agile, or has very little review or QC and I can document that process in SA-4(2) - SA-3+SA-4(2) doesn't say much on what principles must be used to define it, just that it has to be defined as "incorporates information security considerations".  SA-4(3) says more about how it should be defined.  SA-4(3) requires demonstration of "system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes". These are far more prescriptive than SA-3.

SA-8 is also very different from either of the above - adding "Security engineering principles" which it defines in more detail. SA-4(3) does indeed reference "Security engineering methods" as one of the attributes but not only those.  So I would say SA-4(3) is more expansive whereas SA-8 is specific to one of those items.

Clearly CCM is less interested in legacy governmental processes and leaves much more to the practitioner to define. When you are negotiating $10B contracts with a government supplier you probably need far more detail than when negotiating a $100K commercial contract.  And you would expect to pay more for the audits, too!

So I would sum up that if things truly are "gaps" (case i above) or the controls are poorly defined (cases ii and iii above) then one or the other frameworks might be inappropriate for mapping - it's always fine to say "I can't map X to Y" IMHO. But in the case of CCM to NIST 800-53 noted above, I think you need to have explicit mappings to each of the NIST 800-53 controls since they are very different and non-overlapping requirements. And your SLDC should explicitly define how it meets each of these even if CCM doesn't explicitly call them out and leaves it as an exercise to the practitioner.




------------------------------
Robert Ficcaglia
CTO
SunStone Secure, LLC
------------------------------

Original Message:
Sent: Dec 18, 2021 03:00:09 AM
From: Johan Olivier
Subject: Map to Single or Multiple Target Controls (even though gap is closed)?

Good day fellow participating professionals. Please allow me to ask your advice.

The example I use to illustrate my question is taken from the CCM v4 to IBM CFFS controls mapping exercise, but let's not limit the discussion to only the CCM to IBM CFFS mapping exercise. I am keen to hear what you think is the best way to approach any such scenario in current and future mappings regardless of the framework. I am cognizant that the mapping methodologies vary from time to time, and we might need to handle each initiative on a per-case basis.

The question at a high level:
If we map a single control from CCM to any target framework, and the target framework contains multiple controls that describe the same set of requirements and any of them can close the gap;
(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For example:
CCM Control 1 requirement: Stop the tap from leaking water.
Target framework control 1: Do not leave the tap open so it would not leak water.
Target framework control 2: Close the faucet.
Target framework control 3: The valve should be closed tight to not leak fluid.

Mapping CCM Control 1 to Target framework control 1 will be accurate and will close the gap.
a) Should CCM control 1 map to the Target framework controls 1,2 &3? or,
b) Should CCM control 1 map to the Target framework control 1, and because the gap is now closed ignore target framework controls 2 & 3?
c) Any other suggestions?

Real-world scenario using CCM to NIST mappings:
Please consider the following NIST controls - SA-3, SA-4(3), SA-8, and SA-4(2) – all listed below.
It appears to me that SA-3, SA-4(3), SA-8, and SA-4(2) all clearly describe the need for a well-defined SDLC.

Let's consider the requirement of a CCM v4 control such as AIS-04: 'Secure Application Design and Development' – 'Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization.'

If we want to map the CCM control (AIS-04) requirement to NIST 800-53-r5, it appears the NIST 800-53-r5 control SA-3 will be an accurate map, and it contains a sufficient degree of detail to completely close the gap. How should we handle the remaining NIST 800-53-r5 controls SA-4(3), SA-8, and SA-4(2)?

The NIST 800-53-r5 contains the following controls:
SA-3:
'The organization:
(a) Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;
(b) Defines and documents information security roles and responsibilities throughout the system development life cycle;
(c) Identifies individuals having information security roles and responsibilities; and
(d) Integrates the organizational information security risk management process into system development life cycle activities.
Supplemental Guidance: A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies.'

SA-4(3): 'The organization requires the developer of the information system, system component, or information system service to demonstrate the use of a system development life cycle that includes [Assignment: organization-defined state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].
Supplemental Guidance: Following a well-defined system development life cycle that includes state-of-the-practice software development methods, systems/security engineering methods, quality control processes, and testing, evaluation, and validation techniques helps to reduce the number and severity of latent errors within information systems, system components, and information system services. Reducing the number/severity of such errors reduces the number of vulnerabilities in those systems, components, and services.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-4(2): 'The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].
Supplemental Guidance: Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.'

Looking forward to your kind response.

Regards,
Johan Olivier

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------

Hi Robert, thank you for the thorough explanation.
It is true that in many cases, the target framework contains a greater level of specificity than the source framework. Your explanation makes sense and is very helpful. Thanks!

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------

Original Message:
Sent: Dec 20, 2021 07:51:47 AM
From: Robert Ficcaglia
Subject: Map to Single or Multiple Target Controls (even though gap is closed)?

I'll try to unpack this and answer all the questions best I can :)

First your specific questions as stated:

(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For (a) I recommend defining a conceptual vocabulary and articulate what you think each is trying to accomplish in those terms - it's less about whether you have the "right" answer and more how you can explain your methodology to someone else, at least that has been my audit experience.

For (b) we need to better define "gap": i) completely missing requirement ii) redundant/overlapping requirement, iii) ambiguous requirement that is easy to interpret multiple ways, iv) very precisely defined requirement,

I would argue your leaking water example above is an example of ii​ or possibly iii - a poorly defined set of requirements in the target framework that ought have been designed to be non-overlapping (MECE - mutually exclusive, collectively exhaustive). For this - I personally would map them all just for completeness sake and to not have to have the conversation repeatedly why something is not mapped.

Your NIST 800-53 example is an example of iv - the various items you cite are very different and non-overlapping:

SA-3 is about  attributes of a system development life cycle - b) the roles, c) the individuals, and d) the integration of risk management. SA-4(2) is about "different levels of detail in design and implementation documentation" - about the documentation artifacts that must be produced during the execution of a lifecycle. You'd be surprised how many enterprises have a lifecycle doc but no documentation artifacts from the various activities that are part of that lifecycle. For example I can hold a design review session - but do I document it? How? What diagrams are required? Do I do code reviews? How? What documentation is produced? etc. SA-4(2) is telling you to define what level of detail you plan to require.  That will be different for a social media company vs. military weapons system (I hope!)


These are all very different things than demonstrating "state-of-the-practice software development methods" for SA-4(3).  I can define a lifecycle for SA-3 that is waterfall or Agile, or has very little review or QC and I can document that process in SA-4(2) - SA-3+SA-4(2) doesn't say much on what principles must be used to define it, just that it has to be defined as "incorporates information security considerations".  SA-4(3) says more about how it should be defined.  SA-4(3) requires demonstration of "system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes". These are far more prescriptive than SA-3.

SA-8 is also very different from either of the above - adding "Security engineering principles" which it defines in more detail. SA-4(3) does indeed reference "Security engineering methods" as one of the attributes but not only those.  So I would say SA-4(3) is more expansive whereas SA-8 is specific to one of those items.

Clearly CCM is less interested in legacy governmental processes and leaves much more to the practitioner to define. When you are negotiating $10B contracts with a government supplier you probably need far more detail than when negotiating a $100K commercial contract.  And you would expect to pay more for the audits, too!

So I would sum up that if things truly are "gaps" (case i above) or the controls are poorly defined (cases ii and iii above) then one or the other frameworks might be inappropriate for mapping - it's always fine to say "I can't map X to Y" IMHO. But in the case of CCM to NIST 800-53 noted above, I think you need to have explicit mappings to each of the NIST 800-53 controls since they are very different and non-overlapping requirements. And your SLDC should explicitly define how it meets each of these even if CCM doesn't explicitly call them out and leaves it as an exercise to the practitioner.




------------------------------
Robert Ficcaglia
CTO
SunStone Secure, LLC

Original Message:
Sent: Dec 18, 2021 03:00:09 AM
From: Johan Olivier
Subject: Map to Single or Multiple Target Controls (even though gap is closed)?

Good day fellow participating professionals. Please allow me to ask your advice.

The example I use to illustrate my question is taken from the CCM v4 to IBM CFFS controls mapping exercise, but let's not limit the discussion to only the CCM to IBM CFFS mapping exercise. I am keen to hear what you think is the best way to approach any such scenario in current and future mappings regardless of the framework. I am cognizant that the mapping methodologies vary from time to time, and we might need to handle each initiative on a per-case basis.

The question at a high level:
If we map a single control from CCM to any target framework, and the target framework contains multiple controls that describe the same set of requirements and any of them can close the gap;
(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For example:
CCM Control 1 requirement: Stop the tap from leaking water.
Target framework control 1: Do not leave the tap open so it would not leak water.
Target framework control 2: Close the faucet.
Target framework control 3: The valve should be closed tight to not leak fluid.

Mapping CCM Control 1 to Target framework control 1 will be accurate and will close the gap.
a) Should CCM control 1 map to the Target framework controls 1,2 &3? or,
b) Should CCM control 1 map to the Target framework control 1, and because the gap is now closed ignore target framework controls 2 & 3?
c) Any other suggestions?

Real-world scenario using CCM to NIST mappings:
Please consider the following NIST controls - SA-3, SA-4(3), SA-8, and SA-4(2) – all listed below.
It appears to me that SA-3, SA-4(3), SA-8, and SA-4(2) all clearly describe the need for a well-defined SDLC.

Let's consider the requirement of a CCM v4 control such as AIS-04: 'Secure Application Design and Development' – 'Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization.'

If we want to map the CCM control (AIS-04) requirement to NIST 800-53-r5, it appears the NIST 800-53-r5 control SA-3 will be an accurate map, and it contains a sufficient degree of detail to completely close the gap. How should we handle the remaining NIST 800-53-r5 controls SA-4(3), SA-8, and SA-4(2)?

The NIST 800-53-r5 contains the following controls:
SA-3:
'The organization:
(a) Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;
(b) Defines and documents information security roles and responsibilities throughout the system development life cycle;
(c) Identifies individuals having information security roles and responsibilities; and
(d) Integrates the organizational information security risk management process into system development life cycle activities.
Supplemental Guidance: A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies.'

SA-4(3): 'The organization requires the developer of the information system, system component, or information system service to demonstrate the use of a system development life cycle that includes [Assignment: organization-defined state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].
Supplemental Guidance: Following a well-defined system development life cycle that includes state-of-the-practice software development methods, systems/security engineering methods, quality control processes, and testing, evaluation, and validation techniques helps to reduce the number and severity of latent errors within information systems, system components, and information system services. Reducing the number/severity of such errors reduces the number of vulnerabilities in those systems, components, and services.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-4(2): 'The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].
Supplemental Guidance: Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.'

Looking forward to your kind response.

Regards,
Johan Olivier

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------

Hi Johan,

 

A well put and relevant question. Here are my thinking points:

• As the practitioner I want to know how my internal controls align to the target framework so I can identify and address any gaps.
• As the auditor I want to know how the target standard might be applied in the target internal control environment so I don't waste my clients time - and sully my reputation - by issuing control gap observation the are not true.
• To serve these needs it makes sense to me the mapper should take the "you might find the answer here - or over there" approach.

 

Cheers!

------------------------------
Denny Dean CISSP, CISM, CISA, ITIL-F
------------------------------

Original Message:
Sent: Dec 18, 2021 03:00:09 AM
From: Johan Olivier
Subject: Map to Single or Multiple Target Controls (even though gap is closed)?

Good day fellow participating professionals. Please allow me to ask your advice.

The example I use to illustrate my question is taken from the CCM v4 to IBM CFFS controls mapping exercise, but let's not limit the discussion to only the CCM to IBM CFFS mapping exercise. I am keen to hear what you think is the best way to approach any such scenario in current and future mappings regardless of the framework. I am cognizant that the mapping methodologies vary from time to time, and we might need to handle each initiative on a per-case basis.

The question at a high level:
If we map a single control from CCM to any target framework, and the target framework contains multiple controls that describe the same set of requirements and any of them can close the gap;
(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For example:
CCM Control 1 requirement: Stop the tap from leaking water.
Target framework control 1: Do not leave the tap open so it would not leak water.
Target framework control 2: Close the faucet.
Target framework control 3: The valve should be closed tight to not leak fluid.

Mapping CCM Control 1 to Target framework control 1 will be accurate and will close the gap.
a) Should CCM control 1 map to the Target framework controls 1,2 &3? or,
b) Should CCM control 1 map to the Target framework control 1, and because the gap is now closed ignore target framework controls 2 & 3?
c) Any other suggestions?

Real-world scenario using CCM to NIST mappings:
Please consider the following NIST controls - SA-3, SA-4(3), SA-8, and SA-4(2) – all listed below.
It appears to me that SA-3, SA-4(3), SA-8, and SA-4(2) all clearly describe the need for a well-defined SDLC.

Let's consider the requirement of a CCM v4 control such as AIS-04: 'Secure Application Design and Development' – 'Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization.'

If we want to map the CCM control (AIS-04) requirement to NIST 800-53-r5, it appears the NIST 800-53-r5 control SA-3 will be an accurate map, and it contains a sufficient degree of detail to completely close the gap. How should we handle the remaining NIST 800-53-r5 controls SA-4(3), SA-8, and SA-4(2)?

The NIST 800-53-r5 contains the following controls:
SA-3:
'The organization:
(a) Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;
(b) Defines and documents information security roles and responsibilities throughout the system development life cycle;
(c) Identifies individuals having information security roles and responsibilities; and
(d) Integrates the organizational information security risk management process into system development life cycle activities.
Supplemental Guidance: A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies.'

SA-4(3): 'The organization requires the developer of the information system, system component, or information system service to demonstrate the use of a system development life cycle that includes [Assignment: organization-defined state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].
Supplemental Guidance: Following a well-defined system development life cycle that includes state-of-the-practice software development methods, systems/security engineering methods, quality control processes, and testing, evaluation, and validation techniques helps to reduce the number and severity of latent errors within information systems, system components, and information system services. Reducing the number/severity of such errors reduces the number of vulnerabilities in those systems, components, and services.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-4(2): 'The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].
Supplemental Guidance: Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.'

Looking forward to your kind response.

Regards,
Johan Olivier

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------

Hi Denny,
Thanks for the input. I appreciate it and I agree with you.

Kind Regards,
Johan

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------

Original Message:
Sent: Dec 20, 2021 07:57:56 AM
From: Denny Dean
Subject: Map to Single or Multiple Target Controls (even though gap is closed)?

Hi Johan,

 

A well put and relevant question. Here are my thinking points:

• As the practitioner I want to know how my internal controls align to the target framework so I can identify and address any gaps.
• As the auditor I want to know how the target standard might be applied in the target internal control environment so I don't waste my clients time - and sully my reputation - by issuing control gap observation the are not true.
• To serve these needs it makes sense to me the mapper should take the "you might find the answer here - or over there" approach.

 

Cheers!

------------------------------
Denny Dean CISSP, CISM, CISA, ITIL-F

Original Message:
Sent: Dec 18, 2021 03:00:09 AM
From: Johan Olivier
Subject: Map to Single or Multiple Target Controls (even though gap is closed)?

Good day fellow participating professionals. Please allow me to ask your advice.

The example I use to illustrate my question is taken from the CCM v4 to IBM CFFS controls mapping exercise, but let's not limit the discussion to only the CCM to IBM CFFS mapping exercise. I am keen to hear what you think is the best way to approach any such scenario in current and future mappings regardless of the framework. I am cognizant that the mapping methodologies vary from time to time, and we might need to handle each initiative on a per-case basis.

The question at a high level:
If we map a single control from CCM to any target framework, and the target framework contains multiple controls that describe the same set of requirements and any of them can close the gap;
(a) How do we choose the most accurate target control to map to? and,
(b) If the single control closes the gap, what do we do with the remaining controls (do we map them even though the gap has already been closed, or do we ignore them?

For example:
CCM Control 1 requirement: Stop the tap from leaking water.
Target framework control 1: Do not leave the tap open so it would not leak water.
Target framework control 2: Close the faucet.
Target framework control 3: The valve should be closed tight to not leak fluid.

Mapping CCM Control 1 to Target framework control 1 will be accurate and will close the gap.
a) Should CCM control 1 map to the Target framework controls 1,2 &3? or,
b) Should CCM control 1 map to the Target framework control 1, and because the gap is now closed ignore target framework controls 2 & 3?
c) Any other suggestions?

Real-world scenario using CCM to NIST mappings:
Please consider the following NIST controls - SA-3, SA-4(3), SA-8, and SA-4(2) – all listed below.
It appears to me that SA-3, SA-4(3), SA-8, and SA-4(2) all clearly describe the need for a well-defined SDLC.

Let's consider the requirement of a CCM v4 control such as AIS-04: 'Secure Application Design and Development' – 'Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization.'

If we want to map the CCM control (AIS-04) requirement to NIST 800-53-r5, it appears the NIST 800-53-r5 control SA-3 will be an accurate map, and it contains a sufficient degree of detail to completely close the gap. How should we handle the remaining NIST 800-53-r5 controls SA-4(3), SA-8, and SA-4(2)?

The NIST 800-53-r5 contains the following controls:
SA-3:
'The organization:
(a) Manages the information system using [Assignment: organization-defined system development life cycle] that incorporates information security considerations;
(b) Defines and documents information security roles and responsibilities throughout the system development life cycle;
(c) Identifies individuals having information security roles and responsibilities; and
(d) Integrates the organizational information security risk management process into system development life cycle activities.
Supplemental Guidance: A well-defined system development life cycle provides the foundation for the successful development, implementation, and operation of organizational information systems. To apply the required security controls within the system development life cycle requires a basic understanding of information security, threats, vulnerabilities, adverse impacts, and risk to critical missions/business functions. The security engineering principles in SA-8 cannot be properly applied if individuals that design, code, and test information systems and system components (including information technology products) do not understand security. Therefore, organizations include qualified personnel, for example, chief information security officers, security architects, security engineers, and information system security officers in system development life cycle activities to ensure that security requirements are incorporated into organizational information systems. It is equally important that developers include individuals on the development team that possess the requisite security expertise and skills to ensure that needed security capabilities are effectively integrated into the information system. Security awareness and training programs can help ensure that individuals having key security roles and responsibilities have the appropriate experience, skills, and expertise to conduct assigned system development life cycle activities. The effective integration of security requirements into enterprise architecture also helps to ensure that important security considerations are addressed early in the system development life cycle and that those considerations are directly related to the organizational mission/business processes. This process also facilitates the integration of the information security architecture into the enterprise architecture, consistent with organizational risk management and information security strategies.'

SA-4(3): 'The organization requires the developer of the information system, system component, or information system service to demonstrate the use of a system development life cycle that includes [Assignment: organization-defined state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].
Supplemental Guidance: Following a well-defined system development life cycle that includes state-of-the-practice software development methods, systems/security engineering methods, quality control processes, and testing, evaluation, and validation techniques helps to reduce the number and severity of latent errors within information systems, system components, and information system services. Reducing the number/severity of such errors reduces the number of vulnerabilities in those systems, components, and services.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-8: 'The organization applies information system security engineering principles in the specification, design, development, implementation, and modification of the information system. Supplemental Guidance: Organizations apply security engineering principles primarily to new development information systems or systems undergoing major upgrades. For legacy systems, organizations apply security engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware within those systems. Security engineering principles include, for example: (i) developing layered protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii) incorporating security requirements into the system development life cycle; (iv) delineating physical and logical security boundaries; (v) ensuring that system developers are trained on how to build secure software; (vi) tailoring security controls to meet organizational and operational needs; (vii) performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and (viii) reducing risk to acceptable levels, thus enabling informed risk management decisions.'

SA-4(2): 'The organization requires the developer of the information system, system component, or information system service to provide design and implementation information for the security controls to be employed that includes: [Selection (one or more): security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design/implementation information]] at [Assignment: organization-defined level of detail].
Supplemental Guidance: Organizations may require different levels of detail in design and implementation documentation for security controls employed in organizational information systems, system components, or information system services based on mission/business requirements, requirements for trustworthiness/resiliency, and requirements for analysis and testing. Information systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of multiple subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules with particular emphasis on software and firmware (but not excluding hardware) and the interfaces between modules providing security-relevant functionality. Source code and hardware schematics are typically referred to as the implementation representation of the information system. Related control: SA-5.'

Looking forward to your kind response.

Regards,
Johan Olivier

------------------------------
Johan Olivier
Security and Privacy Director
Qorus Software
------------------------------