Monitoring Overlay Syntax Proposal

[Charles Schmidt]

Hello all,

Per my action item from the previous endpoint data collection telecon, I have attached a proposed syntax for a monitoring overlay file. Comments (other than those directed at my inability to create clear and helpful graphical representations of syntax) are welcome.

Charles

[Charles Schmidt]

Resend

[Adam Montville]

Charles (and everyone),

I have some information back from OpenC2 that I thought I’d share before we next meet. They do not have something that approaches our requirements, but they do seem to have something (at least in the works, because they have similar needs) that may be close (I haven’t yet reviewed it myself):  https://github.com/oasis-tcs/openc2-usecases/blob/master/EnergyMashupLab/Reporting%20%26%20Monitoring.md. The author of that document is very interested in comments (I’m seeing how they would prefer feedback - email response or GH issues, etc.).

Additionally, they wonder whether we’d be amenable to the idea of working with an OpenC2 command instead of creating and distributing a file around. I think we would be.

Finally, a suggestion was made (more for the benefit of whatever OpenC2 ends up doing, I think) to look at owl-time as a way to lay foundations for consistent temporality and causality representations across platforms/use cases.

What I am seeing so far is that monitoring instructions are a need, and that there are multiple groups interested in solutions (at least OpenC2 and SCAP 2.0 - I presume, eventually, SACM would consider the same, and that newer C2 groups, such as CACAO).

Kind regards,

Adam

--
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.
<Monitoring Overlay Syntax Proposal.docx>

[Charles Schmidt]

Hi Adam,

Thank you for having the discussion with OpenC2 and bringing this back. It would be great to try to align the efforts.

I took a look at the reporting and monitoring document and it didn't seem to be the same meaning of "monitoring" that we are talking about. If I am understanding it, the "monitoring" in the document talks about automatically generating reports based on events. What we are talking about is the tasking of pre-deployed sensors with information about how frequently they should take measurements. I've only given the document a brief scan so I may have missed something, but I don't see too much overlap.

Regarding the OpenC2 command - I have no particular preference towards a given syntax, but it will need to be something that can be conveyed as part of a larger assessment request message.

I have no objection to switching to owl-time, however. It looks like it fits our needs reasonably well.

Thanks,

Charles

On Wednesday, June 17, 2020 at 2:48:37 PM UTC-5, Adam Montville wrote:

Charles (and everyone),

I have some information back from OpenC2 that I thought I’d share before we next meet. They do not have something that approaches our requirements, but they do seem to have something (at least in the works, because they have similar needs) that may be close (I haven’t yet reviewed it myself):  https://github.com/oasis-tcs/openc2-usecases/blob/master/EnergyMashupLab/Reporting%20%26%20Monitoring.md. The author of that document is very interested in comments (I’m seeing how they would prefer feedback - email response or GH issues, etc.).

Additionally, they wonder whether we’d be amenable to the idea of working with an OpenC2 command instead of creating and distributing a file around. I think we would be.

Finally, a suggestion was made (more for the benefit of whatever OpenC2 ends up doing, I think) to look at owl-time as a way to lay foundations for consistent temporality and causality representations across platforms/use cases.

What I am seeing so far is that monitoring instructions are a need, and that there are multiple groups interested in solutions (at least OpenC2 and SCAP 2.0 - I presume, eventually, SACM would consider the same, and that newer C2 groups, such as CACAO).

Kind regards,

Adam

On May 15, 2020, at 4:27 PM, Charles Schmidt <schmidt...@gmail.com> wrote:

Hello all,

Per my action item from the previous endpoint data collection telecon, I have attached a proposed syntax for a monitoring overlay file. Comments (other than those directed at my inability to create clear and helpful graphical representations of syntax) are welcome.

Charles

--

To unsubscribe from this group, send email to scap-dev...@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...@list.nist.gov.
<Monitoring Overlay Syntax Proposal.docx>

[Adam Montville]

Hi Charles,

I think there’s misalignment for the term report. I don’t think the author is using the term as we might naturally define it. I’ll quote a paragraph from that markdown file here:

This leads to a requirement for what I call a reporting function. A report may be immediate (what is going on now), delayed (report back at 3:00 or in two hours), triggered (report if this ever happens). It may be rate driven (report if this happens more then 5 times an hour or 5 times a minute). It may track longer term monitoring, and the monitoring could be event based (count each time you see this) or episodic (record the flow rate every five minutes). The monitoring period could be fixed (watch this and report back at 5:00) or polled (watch this and I will come back later to get a report). The polled monitoring could be perpetual AND time limited (watch this and I will come back later to get a report of the last 4 hours).

When I read that paragraph, I think we could nearly replace the term report with the term event (not perfectly). The gist is that they want a system to send information back to home base on some set of predefined criteria: What is going on now (sounds like ad hoc), delayed (sounds like the temporal criteria you mentioned in the monitoring overlay), triggered (sounds like on connect or on change). 

I’ll readily admit that later in the write up, the term report is used in a way that seems to more closely resemble our natural definition. But, then, they mention an example of a report being a Stream as defined in WS-Calendar, which I think is an allusion to this.

So, I think there’s more overlap than there may seem to be on the surface.

I think when differences like this seem to be present its best to have a conversation with all involved to ensure common understanding before drawing any conclusions. Would people on this list be amenable to scheduling a call with the OpenC2 folks who responded to our inquiry for a real-time discussion?

Kind regards,

Adam

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]

Hi Adam,

Thanks for the clarification. I reviewed the document again and realize I got thrown by the examples in the first few paragraphs, but agree it does talk about episodic reporting and thus is better aligned than I had implied. Sorry for the misreading. (I really shouldn't post at the end of the work day. My brain is usually no longer functional by then.)

I personally would have no objection to holding a call with OpenC2. Would others on the team be willing to participate?

Thanks,

Charles

On Thursday, June 18, 2020 at 8:06:32 AM UTC-5, Adam Montville wrote:

Hi Charles,

I think there’s misalignment for the term report. I don’t think the author is using the term as we might naturally define it. I’ll quote a paragraph from that markdown file here:

This leads to a requirement for what I call a reporting function. A report may be immediate (what is going on now), delayed (report back at 3:00 or in two hours), triggered (report if this ever happens). It may be rate driven (report if this happens more then 5 times an hour or 5 times a minute). It may track longer term monitoring, and the monitoring could be event based (count each time you see this) or episodic (record the flow rate every five minutes). The monitoring period could be fixed (watch this and report back at 5:00) or polled (watch this and I will come back later to get a report). The polled monitoring could be perpetual AND time limited (watch this and I will come back later to get a report of the last 4 hours).

When I read that paragraph, I think we could nearly replace the term report with the term event (not perfectly). The gist is that they want a system to send information back to home base on some set of predefined criteria: What is going on now (sounds like ad hoc), delayed (sounds like the temporal criteria you mentioned in the monitoring overlay), triggered (sounds like on connect or on change). 

I’ll readily admit that later in the write up, the term report is used in a way that seems to more closely resemble our natural definition. But, then, they mention an example of a report being a Stream as defined in WS-Calendar, which I think is an allusion to this.

So, I think there’s more overlap than there may seem to be on the surface.

I think when differences like this seem to be present its best to have a conversation with all involved to ensure common understanding before drawing any conclusions. Would people on this list be amenable to scheduling a call with the OpenC2 folks who responded to our inquiry for a real-time discussion?

Kind regards,

Adam

To unsubscribe from this group, send email to scap-dev-endpoint+unsub...@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-endpoint+unsub...@list.nist.gov.

[David Kemp]

OpenC2 defines a control message format in the sense expressed in ICOM diagrams (https://en.wikipedia.org/wiki/IDEF0) - actuator profiles describe "functions" and the control messages that apply to those functions:

                                ^

 C (OpenC2 requests/responses   |

    defined in packet filtering |

    profile)                    |

                                v

                     +----------------+ 

              -----> |  Packet Filter | ------>

         I (packets) +----------------+   O (packets)

We have not given much attention yet to control of data sensors / collectors or cyber-physical systems but that is absolutely in the scope of OpenC2.

When discussing reports or events, a distinction will need to be made between data applicable to the control channel vs. data considered as an output. So an immediate reporting function ("how many packets have been blocked, how many KWh consumed, over the past interval X) could be contained in the response sent over the control channel, but event-based reports, i.e., "events" as you say, whether periodic or triggered, are properly considered Outputs rather than Controls.

OpenC2 absolutely needs to define how to configure that reporting, perhaps using the monitoring overlay syntax and owl-time specifications. That is unarguably within scope.

But IMO OpenC2 would not define the content syntax or protocols used for the events themselves.  There is a whole universe of domain-specific event protocols such as syslog, and OpenC2 should define how to tell a collector function to use one or more of them.  Looking forward to working with SCAP to flesh out how.

Regards,
Dave Kemp
Co-chair OpenC2 Actuator Profile subcommittee

[Adam Montville]

David, thank you for the additional information.

How do we want to continue this? Should we get SCAP and OpenC2 together to continue the discussion in real time?

Kind regards,

Adam

--
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]

Hi Dave,

Thank you for the info. I agree with Adam that we should continue this conversation. (And, as anyone involved with SCAP will agree, we can always use more Daves in our discussions.)

Regarding the "applicable" vs. "output" data distinction, I believe that just about everything SCAP tends to deal with would fall under the "output" category since SCAP tools tend to be security agents that make and report measurements. Would you agree?

We have bi-weekly meetings. I'll send you the invite. If you could join us to support further discussion on this, that would be great.

Thanks,

Charles

Adam

To unsubscribe from this group, send email to scap-dev...@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...@list.nist.gov.

[Charles Schmidt]

Hello all,

David Kemp provided the following:

---

Thanks for the invitation, it was a very interesting discussion.  Our first cut at applying the Monitoring Overlay to OpenC2, developing a schema for the overlay and adjusting the example serializations to fit, is described in  https://github.com/oasis-tcs/openc2-usecases/tree/master/DoD/06-Reporting - .

As we dig into the architecture draft we'll explore how OpenC2 data objects might be embedded in SCAP protocols, or where OpenC2 protocols might fit in.

Regards,
Dave Kemp

---

I encourage everyone to check out this material and provide feedback. Thanks to Dave for putting this together.

Thanks,

Charles

[David Solin]

He might have jumped the gun a little bit considering we haven’t actually committed to the specific structure (particularly with respect to the scheduling functions), but very interesting nonetheless!

--
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.

[David Kemp]

There's no such thing as jumping the gun in brainstorming.  Charles' proposal is a data point, something concrete to poke at to see how the OpenC2 schema methodology could be applied outside it's original domain.  The exercise yielded some insight, so I'd call it a success even if that particular scheduling structure is ultimately discarded.

The form of the proposal was outstanding - a statement of requirements plus two candidate serialized data structures. We usually start with much less :-).  Future ideas expressed in that way make schema development easy, and in turn creating a schema brings rigor and internal consistency to the ideas.

[Charles Schmidt]

I think it is also worth noting that OpenC2 is far ahead of where the SCAP architecture team is in terms of development of the protocol details. As such, any mapping of our proposals to the existing OpenC2 ideas is going to move us forward in terms of concreteness. We'll want to iterate on these ideas, but this is definitely forward progress.

Charles

On Thursday, June 25, 2020 at 6:40:17 PM UTC-5, David Kemp wrote:

There's no such thing as jumping the gun in brainstorming.  Charles' proposal is a data point, something concrete to poke at to see how the OpenC2 schema methodology could be applied outside it's original domain.  The exercise yielded some insight, so I'd call it a success even if that particular scheduling structure is ultimately discarded.

The form of the proposal was outstanding - a statement of requirements plus two candidate serialized data structures. We usually start with much less :-).  Future ideas expressed in that way make schema development easy, and in turn creating a schema brings rigor and internal consistency to the ideas.

On Thu, Jun 25, 2020 at 6:05 PM David Solin <so...@jovalcm.com> wrote:

He might have jumped the gun a little bit considering we haven’t actually committed to the specific structure (particularly with respect to the scheduling functions), but very interesting nonetheless!

On Jun 25, 2020, at 2:35 PM, Charles Schmidt <schmidt...@gmail.com> wrote:

Hello all,

David Kemp provided the following:

---

Thanks for the invitation, it was a very interesting discussion.  Our first cut at applying the Monitoring Overlay to OpenC2, developing a schema for the overlay and adjusting the example serializations to fit, is described in  https://github.com/oasis-tcs/openc2-usecases/tree/master/DoD/06-Reporting - .

As we dig into the architecture draft we'll explore how OpenC2 data objects might be embedded in SCAP protocols, or where OpenC2 protocols might fit in.

Regards,
Dave Kemp

---

I encourage everyone to check out this material and provide feedback. Thanks to Dave for putting this together.

Thanks,

Charles

--

To unsubscribe from this group, send email to scap-dev...@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...@list.nist.gov.

--
To unsubscribe from this group, send email to scap-dev...@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...@list.nist.gov.