Minutes from Aug 5, 2020 Teleconference
Charles Schmidt
Attending: Stephen Banghart (NIST), Bill Munyan (CIS), Dave Kemp (DOD), Dan Haynes (MITRE), David Solin (Joval), Masato Terada (Hitachi), Danny Martinez (HII-TSD)
The group discussed the recent meeting with the Open Cybersecurity Alliance (OCA)
- Charles reported that the OCA project review board seemed very interested in having the SCAP framework prototype be an OCA project. So far, 7 people have voted, all in favor of the project being adopted by OCA. We need 17 total to become an OCA project.
- Stephen asked what happens if the prototype becomes an OCA project. Charles said that, in the short term, not much. OCA might be able to find people who can help with development and OCA members might provide agents which could act as PCEs, but probably not immediately. Being an OCA project will give the prototype more visibility, however.
- Stephen asked if OCA places any restrictions. Charles reported that it did not. OCA might recommend certain technologies (e.g., OpenDXL) but they won't control the design.
- Charles noted that we will, ultimately, need to identify a mutually acceptable open source license under which the work can be released.
The group discussed the SCAP v2 Architecture document.
- Dave K. asked about the difference between a report and query requests. Charles responded that a query just checks the Repository for previous results, while a report requests an assessment that might include Repository data but will collect any missing data from enterprise assets.
o It was noted that both types of request will likely have very similar parameters, suggesting that they might reasonably be unified.
o Charles noted that the rationale for separating was that a query to the Repository would not need the Manager to act as a middleman, while a request for a report would require Manager orchestration. The goal of separation was to avoid unnecessary dependency on the Manager. That said, the current prototype design routes both types of messages through the Manager anyway.
- Danny M. asked if freshness criteria were set by the architecture or if it was a parameter in requests. Charles responded that it was the latter.
- Dave K. asked about the difference between a Check System and a Check Type. Charles clarified that a Check System was tied to a language (e.g., OVAL, PowerShell, Ansible, etc.). A Check Type might just be a language, but might represent a finer division. A Collector routes instructions to PCE/PCXs based on the Check Type of a given set of instructions. The group has discussed, but has not come to a final consensus, as to whether it is practical to send different types of OVAL checks to different PCEs. This will be something we would like to experiment with in the prototype.
- Danny M. noted that some messages in the architecture have explicit acknowledgement messages while others do not and wondered if this was intentional. Charles and Dave S. noted that the intent of the message fabric was to relieve SCAP components of the responsibility for providing reliable message delivery. If the message fabric can ensure reliable delivery, then the components would not need explicit acknowledgement messages. (It was noted, however, that OpenDXL does not ensure reliable delivery.) Danny noted that OpenC2 can operate with and without explicit message acknowledgements.
- Danny M. asked how an Application would be able to tie results to a request. Charles noted that the Manager assigns a transaction ID to all requests and this is shared with the Application. (This is the reason that a report request includes an explicit acknowledgement – this acknowledgement conveys the transaction ID to the Application.)
- Danny M. thought that, in an OpenC2 environment, it might make sense for instructions and acknowledgements to be sent using standard OpenC2 messages, but that delivery of results might occur separately without employing OpenC2. Charles felt this was reasonable. Danny noted that OpenC2 had separate response signals for "request received" and "request fulfilled", which could be used to signal an Application that an assessment had started and when it concluded.
- Danny M. noted that the naming of messages appears inconsistent in the architecture. E.g., A Collection Request is sent to initial collection, but the resulting message is a Report Result. Danny suggested that request-response pairs should be visibly related. Charles agreed.
- Danny M. asked if communications to the Repository should employ OpenC2, noting that most repositories would be products with their own, proprietary interfaces. Charles said that the group wanted a standardized interface to the Repository, possible as an overlay over proprietary DB interfaces, to ensure that all components could make the appropriate interactions with the Repository.
- Danny M. noted that his team has some tools for a reference implementation for OpenC2 and once the SCAP prototype is a bit more advanced this can be used to start mocking up interactions.
- Dave K. is working on a some command structures to capture the SCAP interactions. It was agreed that he and Danny H. could both proceed independently for a bit longer, but that we should then synchronized the efforts.
- Charles will take all feedback and revise the Architecture ahead of the next SCAP data collection meeting.
Adam Montville
--
To unsubscribe from this group, send email to scap-dev-endpo...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-endpoint
---
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-endpo...@list.nist.gov.
Charles Schmidt
On Thursday, August 6, 2020 at 7:48:16 AM UTC-5, Adam Montville wrote:
Hi Charles and team… I unknowingly provided some misinformation about the OCA ballot. There are 20 voting members of the PGB, so a majority requires 11 votes.That said, another “yes" vote came in yesterday, so the count is now up to 8. Three to go.Kind regards,
Adam
To unsubscribe from this group, send email to scap-dev...@list.nist.gov
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev...@list.nist.gov.
David Kemp
To unsubscribe from this group, send email to scap-dev-endpo...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-endpoint
---
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-endpo...@list.nist.gov.
Charles Schmidt
On Thursday, August 6, 2020 at 1:20:37 PM UTC-5, David Kemp wrote:
It was mentioned that SCAP v1.3 had been officially published / announced? And that a link would be provided.