PACE
PACE copied to clipboard
opencybersecurityalliance
Should the PAR be in scope for PACE?
@adammontville asked this question as part of #7 comments. This issue was created to escalate it to an issue of it's own so discussion could take place independent of the other scope issues
I feel strongly that PAR is within scope of OCA (hopefully no controversy there) and that given it needs to be somewhere in OCA, that PACE is the best place for it. Otherwise we’ll need another subproject to define the PAR interfaces and functionality.
Note I only think PACE should go as far as defining the blue/green/pink lines in https://github.com/sparrell/PACE/blob/arch2/docs/Arch/pace_arch_3.png and defining the functional requirements on the PES, PCS, PAR boxes.
Should we have potential open source implementations of any of the PACE components, I do not think we should “pick a winner” and allow for multiple implementations for the foreseeable future. I am NOT proposing Ogres as "the" solution to PACE, just "one of many potential" solutions.
- Defining interface(s) to PAR is certainly within scope for PACE
- There initially may be multiple interfaces to the PAR to allow comparison.
- A PoC would (almost by definition) be one of many potential solutions.
- Implementation of PAR is out of scope. PACE participants could use OSS or commercial repository products, deployed on-prem or in the cloud (e.g., https://medium.com/google-cloud/apollo-graphql-server-on-google-app-engine-in-under-5-minutes-bbd64050e9ff).
One question to answer first is "what are the decision-making components that require posture evaluation" trying to find out? Or if the decision-making component is a human, what does his operator console show? I'm all excited about a graph API because if they want to know what's in SBOMs they can get whatever they want from the PAR.
I know we're here to create actual solutions. I think we're also here to specify for others to implement solutions. I think I said this on the mailing list, but the actual PAR implementation should not be in scope for specification. We will likely want to provide some PAR implementation conforming to the interface specification as part of our overall solution, but that implementation (which I hope is really just using some openly available, reliable graph database or triplestore) is not in scope for our specification.
Is there a generalized design principle we can derive from this scenario? Something about solutions vs. specifications? Keep in mind that I'm coming from the "standards first" approach, which is backwards from what we're trying to do here.
By definition a prototyping effort should be working to create functioning artifacts, AKA solutions. But that doesn't mean we need to build everything from scratch. But we should be defining interfaces, and prototyping implementations that demonstrate those interfaces. If the prototype can be built on top of an off-the-shelf component that's a solid approach unless we've got some good reason not to do so. None of which should stop anyone from going farther on the implementation if they've got desire, resources, and capacity.
