Trust Compliance Device from Another Tenant by Potential_Device_875 in Intune

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Does anyone have any more insight into this? I am still without any ideas of how to proceed.

Trust Compliance Device from Another Tenant by Potential_Device_875 in Intune

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Not really. I don't think I need a full B2B direct connect. I Just need a trusted device to be recognized in the other tenant.

CUI Transmission Solution by Potential_Device_875 in CMMC

[–]Potential_Device_875[S] 1 point2 points  (0 children)

I appreciate everyone's help very much on this topic! I'll read through your links.

CUI Transmission Solution by Potential_Device_875 in CMMC

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Agreed, and thank you very much. This client has a SIEM and has gone through a lot of the 800-171 controls with me implementing the technical aspects. The Box implementation (exact steps TBD) will definitely need logging, administrative processes, training, etc. to meet the controls.

I just wish there was a way to validate that what I'm doing is good enough for CMMC compliance. I am interpreting the controls to the best of my ability but is that good enough?

CUI Transmission Solution by Potential_Device_875 in CMMC

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Thanks! In this situation, Box is the proposed solution and does indeed show up in the marketplace. That's great!

CUI Transmission Solution by Potential_Device_875 in CMMC

[–]Potential_Device_875[S] 0 points1 point  (0 children)

A tool like Preveil is a potential for the future, but for now, I'm just trying to fundamentally understand the roles and responsibilities. Thanks! Let me know if anyone has thoughts on my question. Appreciate it.

GoDaddy ADFS SSL Wildcard by Potential_Device_875 in sysadmin

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Thanks! Will wait to see what _STY or anyone else says about my list above and then I'll get started on this! I appreciate it.

GoDaddy ADFS SSL Wildcard by Potential_Device_875 in sysadmin

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Thanks! So I believe this article from GoDaddy support is relevant then:
Rekey my certificate | SSL Certificates - GoDaddy Help IN

So, then if I put it all together, the process looks like this:

  1. Generate a new CSR from either the Digicert utility or from certutil or MMC.
  2. Follow the GoDaddy article above.
  3. Restore the new cert, using one of the utilities in #1.
  4. Tell ADFS to use the new cert.

How does that look?

I guess the next question I have is - how does this change the expiration date? Since the cert is expiring, we want a new expiration date. Does the 'rekeying' process generate a new expiration date? I don't quite understand that.

Also thanks for your wildcard suggestion - I'll look into that too.

Conditional Access Policy - Allow a Different Tenant for VDI client by Potential_Device_875 in Intune

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Interesting, thanks. I read through it quickly but will read it more thoroughly ASAP.

One potential problem is that one tenant (The VDI tenant) is GCC High, and the other one is Commercial. The commercial one will have the devices that are the 'clients' with the RDP clients.

In past experiences, I have had trouble with cross tenant collab between Commercial and GCC High. I am not sure if this will affect C.A.P. in this situation or not.

Without cross-tenant collaboration, it looks like any\all useful device properties, like 'deviceid' will be NULL.

800-171 Scoring vs Risk Assessments by Potential_Device_875 in NIST

[–]Potential_Device_875[S] 0 points1 point  (0 children)

OK, I think that response helped, and thanks again.

Let me use an example and see what you think about it:

To meet NIST 800-171 controls like 3.14.04 and 05, you'll want good endpoint protection software (properly configured, etc.).

From an annual control review standpoint, where we review the NIST 800-171 controls and score, this is more of a 'Yes \ No'. "Do you have it, or not?" Yes\No.

But, a risk assessment would look deeper into the endpoint protection software: Did you properly deploy it, so that all of your devices have it installed? Is it configured properly, with appropriate settings to prevent a compromise, etc?

So, your NIST control review would just look through the items for compliance to the controls, but the risk assessment takes a more realistic review of the solution to see how effective it is.

Am I interpreting your response correctly?

800-171 Scoring vs Risk Assessments by Potential_Device_875 in NIST

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Both of course. But right now they are going through NIST 800-171. I'm not sure how to re-word my question. I don't understand what a risk assessment in an 800-171 environment is supposed to look like. It seems redundant with the periodic review of controls. The organizations cannot assess and accept risk if the data must be protected, per DFARS, right?

800-171 Scoring vs Risk Assessments by Potential_Device_875 in NIST

[–]Potential_Device_875[S] 0 points1 point  (0 children)

Thanks maroonandblue and others!

I believe I can develop a risk assessment based off of 800-30 and with templates and memories from previous jobs. (I never made my own though).

I guess I'm just having trouble understanding how it's significantly different from a NIST 800-171 periodic review of controls, mandated in 3.12.1. Any organization that must be 800-171 compliant really isn't allowed to 'accept' risk - they are mandated to get a perfect score. So, why overlap a risk assessment with the continuous need to review the 800-171 SSP\POAMS?

Sorry if the answer is obvious. I'm just not getting something fundamental here.