Temporality - time args

[Vasileios-Mavroeidis]

A suggestion for more refined time args that we may consider. Temporal arguments make sense for a wide range of actuators/technologies. The current state of the time args is limited.

Currently, we support start_time, stop_time, and duration

even though they make sense to have, a different categorization would be more useful.

Suggestion:

Parent classes:
-absolute_time
-periodic_time

Absolute_time can include start_time, stop_time, duration
Periodic, it is what it sounds, and it can support the following:
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
daily
weekdays
weekend
start_time (without defined date)
stop_time (without defined date)
or duration (instead of using stop time)

After bringing this topic up to the actuator profiles subcommittee, Patrick Maroney suggested also to reference the time ontology https://www.w3.org/TR/owl-time/ for suggestions.

[jmbrule]

OK, I see the point being made, and by the way I am NOT agreeing or disagreeing with the notion of periodic at this point, but a couple of things to consider:
ONE: For the actuator, do we want to impose the notion of a day of the week, a year, dealing with leap year etc? Or should we stick to the notion of the unix epoch which is in fact a simple integer number of seconds since 1971? It makes perfect sense to me that at the orchestrator, we may want to say 'push the patches on Monday', but for the actuator, would be easier to simply send UPDATE START_TIME = 1617220800 (which happens by to be a very important date to me ;-) )
TWO: I know that conversion from human readable to unix time is readily available and would not be too terribly burdensome for a lot of the actuators, but what about some of the processing constrained actuators? that way may encounter in SCADA or IoT eco-systems?
THREE: The use case is easy enough to see, (patch on Monday is one of many examples) but is this a scope creep? Patch on Monday seems like a routine configuration management thing, and not an 'Act' in response to a cyber event...

Good topic, looking forward to the discussion

[Vasileios-Mavroeidis]

Good points Joe.

I was mainly focusing on point 3.

I guess we could solve many of our issues if we had a "sophisticated" orchestrator but this is not the scope of our work.

granular temporality for fw rules would be beneficial. The simplest example is: Dont ask me to use openc2 to respond to an incident but CLI and manual config when I'm supposed to submit a rule that provides additional security (periodic) but is not an action for an incident. Maybe I need to find better a better use case.

Another simple example for EDR. In the light of CTI for an attack campaign targeting national critical infrastructure, i have some IOCs that i want to inspect if exist in my infrastructure periodically (it may be a command directly into a SIEM or EDR technology). Scan for this * periodically in the following systems.

Let's wait for more concrete use cases.

[TobyConsidine]

This topic just touches on time, and in particular human-centric time (in which days of week and time of day matter) and further into schedules (maintain security posture from close of business to opening of business), and tightening down on the M2M aspects of schedule.
Perhaps it is OK to specify only that a particular action endure for 2 hours, or for so many microseconds, in which case Unix Time and Java Duration are adequate. But I have always viewed OpenC2, as a service-oriented security, not specifying precise actions but effects, as not as mechanistic.
The starting point for computer representation of time and duration is ISO8603. There are low level Java libraries for interacting with durations as well as time in these expressions.
Do we imagine night-time vs day-time security, especially when communicating with Cyber-Physical Systems? If so, we would want to be able to guard against specific types of attacks (set security actions) dependent upon the schedule of the humans and business operations interacting with the CPS.
We have talked on calls, for example, whether OpenC2 might refer to physical Access Control systems as well as firewall based Access Control Systems. This is what makes Tuesday different than an arbitrary range of seconds in Zulu time. Local all doors at the close of business may have a different start time in each time zone, not to mention each business (“Now open Saturday in the greater Cleveland area!”) Schedules as well as times may be worth exchanging.
When we looked at Time and coordination of Smart Energy, we looked deeply into these areas. Those conversations required some specific schedule-dependent commercial agreements. (We are contractually obligated to respond within 10 minutes during business hours or within an hour after hours except during the annual plant-shutdown.) These were expressed as overlaying availability in unavailability objects, each availability object itself potentially limited by a start and end schedule.
The Common internet expression of these elements is in ICalendar (updated from RFC 2445 to RFC 5545 in work parallel to the smart energy work). Icalendar includes several one-offs touched on above. Calendar Availabiltiy, RFC 7953, for example deals with recurring patterns of time. Patterns of time might describe business hours, and the annual plant shut-down might be an unavailability laid down over it.
I can imagine a directive to [tighten up the firewall] during all non-business hours when the site will not be monitored as closely. I can imagine events being suspicious if they occur after hours except during the annual late-night sale, or except when using the “red-alert” schedule. But what are these, and how are they shared between a central security monitoring point issuing directives, and distributed heterogenous systems.

[TobyConsidine]

Ahh, and I left out the references. See the relatively abstract "WS-Calendar Platform Independent Model (PIM) for M2M schedule negotiation. It is an ASHRAE recommendation, for example, that it be built into HVAC systems. It is at the heart of communications of the smart grid. It appears that some very small devices are learning to understand it. http://docs.oasis-open.org/ws-calendar/ws-calendar-pim/v1.0/ws-calendar-pim-v1.0.html

[dlemire60]

A reminder that 32-bit representations of Unix epoch time are kaput in 2038: https://en.wikipedia.org/wiki/Year_2038_problem

While machines can easily communicate in epoch time, and convert it to/from human-readable form for HMIs, I get a clear sense from @Vasileios-Mavroeidis's and @TobyConsidine's messages that the needs are more complicated than just representing time values, so something more than epoch time seems worth incorporating into OpenC2. I don't know enough about any aspect of this to actually suggest which of a number of available time standards actually makes sense to adopt, however, so I'll have to trust to people more informed than I to make good choices.

[dlemire60]

I believe this remains a valid issue, and one it is probably desirable to resolve for v1.1 in order to reduce the potential need for future breaking changes.

[dlemire60]

Discussed at triage, defer to future, needs use case & proposal.