"Duplicate" Control Objective Names, but different source NIST800-53 R4 vs R5 question

Valqe
Tera Expert

Hi all,

Due to Control Objective source "NIST 800-53-r4" and "NIST 800-53-r5" I'm noticing 'duplicate' control objectives (with same name, but with different source)

Example

Reference: AC-1, Source:NIST 800-53-r4

Reference: AC-1, Source:NIST 800-53-r5

 

What is you best practice when it comes to mainining control objectives is such situation. Ideally I would like to see on "r5" ones, but I highly welcome your approach to dealing with them and which one(s) are you using.

 

Thanks in advance for your comments.

V.

1 ACCEPTED SOLUTION

Community Alums
Not applicable

Hi @Valqe ,

I would take this back to my compliance team in the company to verify if my company want to comply with  NIST 800-53-R5 (over R4) , what's their preference. Based on the input i get, i would either make the duplicate record as inactive or refrain from using.

 

View solution in original post

3 REPLIES 3

Community Alums
Not applicable

Hi @Valqe ,

While Importing the Control objectives, you can write a Transform map with coalesce on "Name" Field in the 

sn_compliance_policy_statement table.

SandeepDutta_0-1712585581175.png

 

The coalesce option allows you to update existing target table records when transforming import data.

The coalesce option on a field map allows you to specify if the selected Target field should be used to coalesce on when import set records are transformed. If the field map Coalesce checkbox is selected, when the import set row is transformed the instance checks for an existing record in the target table that has the same value in the Target field as the import set row Source field.

If an existing record with a matching value in the target table is found, that record is updated. If no matching record is found, then a new record is created in the target table.
 

 

Valqe
Tera Expert

Thanks for your quick response @Community Alums  - I appreciate your comments.

My issue is that I did not import control objectives at all. They got automatically created/populated when NIST Use Case Accelerator plugin got installed/updated. Such records got pushed by ServiceNow.

Based on your experience, I want to guess you would take advantage of NIST 800-53-R5 (over R4) - would that be a good asumption? Also, do you think it is a good idea to set ative=false for R4 ones? (issue in this situation is that control objectives that are linked to a published policies get read-only and there is no way to modify them with published policies). 

I welcome best practices and comments on this situation 🙂
Thanks in advance

Valqe

Community Alums
Not applicable

Hi @Valqe ,

I would take this back to my compliance team in the company to verify if my company want to comply with  NIST 800-53-R5 (over R4) , what's their preference. Based on the input i get, i would either make the duplicate record as inactive or refrain from using.