create the proposed architecture and sequence diagram for CAML

[rajkrishnamurthy]

You will find the hand-drawn picture under misc/ folder. Need to create a formal architecture and sequence diagram. We also should outline the priorities for development based on the working group discussion on 11/22/2021.

[pritikin]

(from group conversation)

we need to clarify what our vision is for modularity / expandability. How is this solution distinct from the "classic" GRC model of an internal script that works against internal GRC tooling but doesn't natively integrate with the systems already deployed within an organization?

@rajkrishnamurthy in conversation today we discussed that you have some well formed thoughts on this in an email exchange that mosi will share. Looking forward to continuing the conversation.

[mosi-k-platt]

Here is the point @rajkrishnamurthy shared with us at Netflix about GRC automation:

One of the biggest problems with automating GRC, as you know, is the ability to map from “Intent” to “Implementation”. For example, “limit administrative access” (say, SSH) can be implemented many different ways; handled at a firewall, dropping the packets at eBPF filter etc. depending on how the customer has designed and architected the solution. GRC, as a platform, takes a standard approach to user workflow, irrespective of the underlying framework such as ISO or PCI-DSS. However, in order for them to allow customers to “express” these policy rules for effective compliance, they will need to depart from the traditional “one size fits all” approach and need to take an open systems approach. I don’t know of any GRC product that does that today. I think that they will all get there eventually but are not there now.

[pritikin]

Raj speaks sense in his comments about GRC automation. I agree w/ an open systems approach and the proposed architecture needs must make is clear how this is achieved here in our work.

In a related topic the US government accountability office comments on CMMC work (ref: GAO-22-104679 ) includes this note: "Assessment consistency: Industry and members of the CMMC ecosystem expressed concern about the consistency of assessments across assessment organizations. During our discussion group with small defense contractors, participants told us that each practice is subject to interpretation and DOD has not provided sufficient guidance on how the practices should be assessed. They also said that without additional guidance, any company could fail an assessment depending on how an assessor interprets each practice. In public comments on the DFARS interim rule, one commenter stated that assessors will have to apply subjective judgements about what is sufficient to adequately address a requirement. Representatives from DIB companies that conduct cybersecurity assessments we spoke to raised similar concerns. The officials said DOD has not provided standards for evaluating evidence during an assessment. They noted that the current assessment guides identify the types of evidence that assessors should consider but do not identify how they are to interpret the evidence. As a result, two different assessors could look at the same evidence and come to different conclusions."

These could be seen as contradictory requirements. In one space Raj points out that a "one size fits all" approach is problematic where one could interpret the GAO comments as arguing in favor of "one size fits all" for consistency. I think though that our metrics approach can thread this needle. The metric definition provides consistency and the open systems approach allows for flexibility in how an organization collects the measures. The assessment guidance can focus on what types of measures are reasonable and within industry 'best practices'. To an extent 'best practices' are mirrored by which open systems integrations are available.