Minutes from the Data Collection Telecon of May 14, 2020

[Charles Schmidt]

SCAP Data Collection Telecon, May 14, 2020

Attending: Charles Schmidt, Danny Haynes (MITRE); Jessica Fitzgerald-McKay (DOD); Bill Munyan (CIS); David Solin (Joval)

Discussed the thread regarding Adam's concerns that we were creating an architecture that was too "monolithic".

• -          Charles felt that the general consensus from this thread is that the message fabric should be employed wherever possible. In particular, capabilities that could be handled by the message fabric should not be embedded into SCAP components. Using the message fabric instead creates greater flexibility in communication flows and avoids single points of failure.
• -          Charles added that, within this consensus, there still seems to be some question as to which capabilities could reasonably be handled by a general message fabric vs. those that require SCAP specific intelligence and reasoning, and thus would require special implementation.
• -          David agreed in principle but noted that we want to be ware of capabilities that only appear in certain message fabric implementations. He felt that we should be wary of "clever implementations" that might bind us too tightly to specific products. Others agreed.
• -          Bill clarified that he felt Adam was advocating for a more "event driven" or "publish-subscribe" architecture, rather than one that is "request-response". Bill noted that, even when asynchronous, a request-response architecture creates dependencies, and that these can be avoided using a more event-driven architecture. The group agreed that this didn't imply that there would be *no* request-response relationships, since an assessment is kicked off by an Application request and the Application must reasonably expect to get answers at some point in the future. However, the architecture should look to avoid imposing request-response relationships when other options exist that can reduce dependencies.
• -          It was agreed that, at this stage, most of the unresolved details will be best resolved through trial implementations rather than further discussions.

Discussed the thread regarding Adam's concerns that the proposed architecture was overly "OVAL-centric".

• -          Charles felt that the general consensus was that we want the architecture to be able to support a wide range of checking languages and methods. Moreover, we want to make sure that an implementation could add support for a new checking language without requiring alterations of the standards. There seemed to be agreement on this point.
• -          David noted that, while we don't want to limit was is possible, we will probably want to declare a minimal set of languages that are supported so that there can be some confidence that SCAP implementations will be able to handle a certain, minimal set of assessments. Charles agreed that this would probably be desirable.
• -          Bill asked what a minimal set of expectations implied for "validation". Specifically, he wondered if it might be the case that one could have an architecture instance with no OVAL support.
• -          Stephen noted that NIST would likely perform validation on a per-component basis, rather than of architectures as a whole. He noted that this validation is important to many parties.
• -          David noted that it is important to get standardization not only in architecture but in capabilities. The latter would imply a common set of assessment language support that could be assumed across all validated products. The standardized architectures alone would create connections but people wouldn't be able to assume that a given check would actually be run.
• -          Charles noted that there will probably be a difference between what the architecture supports and what NIST validates. He asserted that this isn't a problem as long as the former is a superset of the latter. He noted that this is already with the case of the SCAP standards, where standards such as XCCDF support a greater set of capabilities than what NIST validates.
• -          Charles noted that, on the technical front, Collectors always need three things across any checking instructions they receive: a unique identifier for the check, a way to determine the type of check, and a way to indicate a result of "UNABLE TO RUN" for cases when the type of check is not supported. The type of check is needed to route check instructions to where they can be executed.
• -          There was an extended conversation of what portions of OVAL would be needed to run checks (objects alone, tests, definitions, etc.) David noted that Joval has developed a simplified way of handling OVAL extensions that use a single common structure rather than needing to specify new structures for tests, states, objects, and items.
• -          Charles noted that, as currently understood, the Collector would receive checking instructions, determine the types of these instructions, and route instructions to PCEs and PCXs accordingly. In the case of PCXs, the Collector would likely send the unmodified instructions. For a PCE, the Collector might need to translate the instructions to a form the PCE understands and that PCEs might not understand the instructions the Collector receives. As such, the expectation is that, when instructions arrive that have a type aligned to a particular PCE, the Collector knows how to convert instances of that instruction type to commands the PCE can understand and execute. David's proposal of extracting partial OVAL content would be in line with this design.
• -          Charles asked what constituted a "type" of check. Specifically, was all OVAL one type of check, was each OVAL schema a type of check, or was each OVAL Test type a type of check. This becomes relevant for the architecture because the Collector would need to be able to examine the content and extract separate checks of each type.

o   Charles recommended that the way to determine the best answer to this question was to look at current implementations of OVAL interpreters. Specifically, while it is known that many tools do not support all OVAL schemas, if there are tools that support a subset of individual schemas, then that would argue for types being individual test types.

o   Bill noted that sometimes the results of one check are used as inputs into a different check, and that these checks might be from different OVAL schemas. If the checks were routed to different PCEs, this could complicate processing.

• The group agreed that the next step forward will be to revise the specification document Charles put together, capturing both the points of consensus and the open questions.
• As the call was only able to get through about half the topics on the agenda, the group proposed switching to a bi-weekly format. A poll will be sent out to determine the best days and times.

========= ACTION ITEMS ===========

Charles – Send out a poll to determine the best days for bi-weekly meetings

Charles – Revise the data collection architecture specification based on team discussions