Notes from June 10

[Charles Schmidt]

Hi all,

Below are my notes from the June 10 teleconference. Comments and corrections are welcome.

Charles

==========

Attending: Charles Schmidt, Bill Munyan (CIS), Adam Montville (CIS), David Solin (Joval), Stephen Banghart (NIST)

Discussed the Monitoring Overlay document that Charles submitted on May 15 (https://groups.google.com/a/list.nist.gov/forum/#!topic/scap-dev-endpoint/UbPq0DhTT38)

• ·         David asked if this proposal had been built based on prior art, like cron. Charles said it had not, but agreed that it would be useful to look and be compatible with prior art on this sort of thing. Stephen noted that OpenC2 and CACAO also had related work. Stephen agreed to look into prior art in CACAO and Adam agreed to look into OpenC2.
• ·         David requested clarification as to the meaning of the "on-connect" periodicity. Charles clarified that the idea was to support a check after a target had been disconnected for some period of time. He noted that this was intended to be similar to a "comply-to-connect" scenario. David noted that some "Connection" is a fuzzy concept for things like images. Charles agreed that it will be necessary to add clarify as to the meaning of "connect"
• ·         Adam asked if, for on-change monitoring, one could indicate that one is monitoring for a specific type of change. (E.g., monitor for a decrease in log file size but ignore increases.) Charles said that he had kept the overlay file focused only on re-check times. Charles felt that the Collector would have the role of distinguishing between "significant" vs. "not-significant" changes. Charles also worried that, if monitoring components were also filtering inputs, it would add duplicative complexity and could create unexpected interactions.
• ·         Stephen asked why the architecture needed anything more than "on-change". Dave and Charles both felt that real-time monitoring of every aspect of a benchmark would be too resource intensive. Charles felt that, some things might be of critical importance and be monitored in real time, some might be important but monitored less frequently due to processing limits, and some things might need to be tracked for auditing purposes but were not actually inputs into operational responses.
• ·         Adam asked whether it was necessary to create a full standard or if it was sufficient to just specify the behaviors the architecture should support without standardizing a structure. Charles and Dave both noted that the monitoring overlays need to serve as inputs to Collectors, and if we want Collectors from multiple vendors to work together, they will need to expect a standard input.

Discussed the question of platform-specific vs. platform-agnostic check instructions

• ·         Charles suggested that it had sounded like there was agreement that, by the time instructions reached Collectors, it would be in a platform-specific format, like OVAL. Others quickly noted that the situation was more nuanced since OVAL has checks that are platform-agnostic, such as those in the platform schema. As such, existing behaviors of current checking languages do not cleanly divide along platform-specific/agnostic lines.
• ·         The group agreed that the SCAP architecture does not need to replace existing checking languages and instead invent something new. Adam clarified that we might wish to be able to accommodate the addition of something new, but agreed that he doesn't believe it makes sense to do away with OVAL.

The group discussed types of instructions

• ·         Charles asserted that, in the current design, PCEs are not constrained in any way in terms of the input they take and the output they produce. A PCE could use any existing standard or some custom proprietary interface and still be able to integrate into the SCAP architecture. It is the Collector's job to understand how to communicate with their associated PCEs. By contrast, the set of valid input formats to Collectors should be relatively limited because, to ensure interoperability in a multi-vendor architecture, all Collectors will need to be able to ingest the same set of input formats. The group broadly agreed with this idea.
• ·         Charles proposed that, when taking inputs and turning them into PCE instructions, a Collector's behavior will generally follow one of two patterns. In pattern 1, the Collector parses the input instructions and then generates new instructions using the PCE's instruction set. In short, the Collector is performing a translation from an input format into a PCE format. In pattern 2, the input is just a wrapper for instructions the PCE understands. The Collector "transforms" this input simply by removing the wrapper and passing the body along to the PCE for processing. Overall, the group seemed to agree with this idea.
• ·         Charles asked what inputs a Collector should take and how should those formats handle the case where they were wrapping other content. Charles agreed to start a thread on this topic to support discussion prior to next week's meeting.

Consensus

The group appeared to reach consensus on the following points:

• -          There likely is a need for a monitoring overlay standard.
• -          There likely is a need for the monitoring overlay to support more than just "on-change" monitoring.
• -          There is no need to develop any new checking languages to replace existing checking instruction languages in the SCAP architecture. The architecture should be able to accommodate new languages, but there is no reason not to support existing languages.
• -          The set of checking languages inputted by Collectors should be relatively small and needs to be standardized for interoperability.

Open Issues

The following remain points of ongoing discussion

• -          The monitoring overlay should align with existing standards and conventions related to dictating periodicity of events. The group needs to determine which prior art is relevant and how to align the overlay design.
• -          The monitoring overlay needs greater clarity on what "connect" means for a wide range of potential targets.
• -          The group needs to decide what checking languages are supported as input by Collectors and how those languages will support "wrapping" of arbitrary content.
• -          The group still needs to scope the extent of a Collector's ability to determine whether new data from a PCE is "significant" vs. "not-significant".

Action Items

Stephen – Reach out to the CACAO team and learn how they handle assessment scheduling.

Adam – Reach out to the OpenC2 team and learn how they handle assessment scheduling.

Charles – Start a thread to discuss Collector input formats.