cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Joro
Newcomer II

Determining Accreditation Boundary's

I am currently working on a NIST 800-171 audit and have found an interesting question. I have a managed switch that separates a non auditing segment (Software Development Segment) with an auditable segment (Enterprise).  More specifically I am preparing for an eventual CMMC level 3 audit and are mostly concerned with CUI data. May I effectively ignore the Software Development side? Any thoughts or experience from any other audit rules?

 

Thanks for your input.

 

joro

3 Replies
AppDefects
Community Champion

Re: Determining Accreditation Boundary's


@Joro wrote:

I am currently working on a NIST 800-171 audit and have found an interesting question. I have a managed switch that separates a non auditing segment (Software Development Segment) with an auditable segment (Enterprise).  More specifically I am preparing for an eventual CMMC level 3 audit and are mostly concerned with CUI data. May I effectively ignore the Software Development side? Any thoughts or experience from any other audit rules?

 

Thanks for your input.

 

joro


All I can say is good luck if you include development in your scope...

Joro
Newcomer II

Re: Determining Accreditation Boundary's

AppDefects, agree on that one. I am just not sure if the switch controls are sufficient separation of the segments to satisfy the auit requirements.
rhall
Newcomer I

Re: Determining Accreditation Boundary's

My understanding (maybe I'm wrong here?) was that systems which do not store, process or transmit CUI data can be considered out of scope with regards to NIST 800-171 and CMMC compliance.

 

On this basis the development environment systems would only need to be included within scope if actual CUI data touches these systems in some way. If only junk/test data is used on the development systems and there is effective network segmentation implemented between the two networks then I would have thought that would satisfy the requirements and auditors with regard to technical controls. Whilst the physical cabling maybe connected through a managed switch you will likely need a firewall somewhere though that manages and restricts data flows between the two network segments.

 

In a production database if records containing CUI are marked as such by having a 1 in the 'cui' column for example, then when extracting a recent set of data to use to aid development and testing, anything with 'cui'=1 can easily be excluded.

 

To address the people and process aspects of limiting your scope, your policy could explicitly state that it is prohibited for CUI to be processed, stored, or transmitted to or from the software development environment, and your developers could be trained in what CUI is and where it is and isn't allowed and why. Signed attendance sheets at this training could be used as evidence to auditors.

 

I'm by no means an expert on this and am also having to figure all this out at the moment but to me the above seems like a reasonable approach.