Minutes from June 24 telecon
Charles Schmidt
SCAP Data Collection Telecon, June 24, 2020
Attending: Charles Schmidt, Bill Munyan (CIS), Adam Montville (CIS), David Solin (Joval), Stephen Banghart (NIST), Jessica Fitzgerald-McKay (DOD), Joe Brule (DOD/OpenC2), Dave Kemp (OpenC2), David Lamire (HII-TSD/OpenC2)
Discussed the relationship between the SCAP architecture, CACAO, and OpenC2
· Stephen said he would see about setting up a conversation with representatives from OASIS CACAO.
· Dave Kemp (OpenC2) reported that he had looked over the Monitoring Overlay design and that he felt it represented a reasonable model for the type monitoring being attempted. He is working on translating that model into the OpenC2 language and reported this was going well. He hopes to have an example schema and example message to share.
· Dave K. reported that OpenC2 defines both a protocol and a data structure. The data structure is intended to be integrated into other efforts (he noted it is hoped that CACAO will do so) and so it should be possible to include OpenC2 structures in any SCAP messages.
· Joe Brule noted that OpenC2 can support both query-respond and post-retrieve models of communications as the intended users of OpenC2 will have need for both.
· Charles summarized the multiple components in the envisioned SCAP architecture (Manager, Collector, PCE, etc.) Joe and Dave K. both reported that this sort of distributed architecture would fit well with OpenC2.
· It was noted that there is not really a tutorial for OpenC2 at this time. (David L. noted that section 1 of the three OpenC2 specifications provides a common overview and might be helpful.) Charles agreed to send out the latest SCAP architecture description so that Joe, Dave K., and David L. could look at the current SCAP vision and consider how OpenC2 might align.
Repository Invocation
· Charles raised a question for Danny Haynes (who is working on a simple implementation of the SCAP architecture). The Repository needs to receive the assessment results from Collectors. Danny was wondering whether the Repository should have an interface invoked by the Collector, or if the Repository should listen to a topic associated with the Collector to which the Collector posts its results. Adam recommended the latter. We will build the initial prototype that way and can re-evaluate the decision based on that experience.
Evaluation on Collectors
· Adam had raised concerns about the degree to which Collectors were expected to perform evaluation during monitoring as described in the original SCAP architecture.
· There seemed to be consensus among all parties that it makes sense to allow Collectors to filter the information they receive from PCEs to reduce the reporting of changes that the Application does not care about.
· The group needs to continue discussions on:
o The best way to control that filtering (whether it should be triggered by the presence of evaluation instructions or some other method)
o The extent of the evaluation that Collectors will be expected to be able to support. (E.g., should Collectors be expected to produce XCCDF Results, which requires XCCDF evaluation)