OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-actuator message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [Non-DoD Source] Re: Firewall Profile: Duration option and persistent option


IN CONTEXT OF TEMPORAL OPTIONS: 

Good point on the timezone issue.  Is this issue mitigated if we add some text along the lines of ‘SHOULD use UTC…’ ?

Regarding ‘start-time’, it makes perfect sense to me that if you receive a ‘duration’ option and you did not receive a ‘start-time’, then now() is implied. 

 

Regarding the end-time:   In the context of the firewall, can we capture the functionality with a single option (in this case duration)?   

 

Our colleague provided a good scenario for the use of duration vice end-time (look at the very end of this email chain).   If someone does not provide a scenario or thread for end-time, then can we go with ‘duration’ is required and either remove or make ‘end-time’ optional to implement? 

 

IN THE CONTEXT OF RUNNING VS PERSISTENT:

Actually received two comments on this (the other person wishes to remain anonymous) 

The gist of the first comment was along the lines that we should define one or the other but not both, BTW sounds good to me. 

The second objection (see below) is concerned with adding unnecessary complications, which in the context of a stateless packet filter;  is a perfectly logical point.  

 

Are we OK if:  

we get rid of the persistent option,

make running optional to implement and

modify the text along the lines of: (note, this is written in the context of allow, but could be for others)

 

Running
optional
Setting the running option to TRUE results in an ephemeral allow, i.e. the traffic will be allowed while the firewall is operating, but in the event of a restart, power down or recovery, the rule will not be  retained. If the running option is set to FALSE, then allow commands SHOULD be persistent, i.e. the rule should remain in place in the event of a restart or similar event.  Default value is FALSE.  

 

 

From: Everett, Alex D <alex.everett@unc.edu>
Sent: Thursday, April 12, 2018 5:32 PM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; openc2-actuator@lists.oasis-open.org
Subject: [Non-DoD Source] Re: Firewall Profile: Duration option and persistent option

 

See inline.

 


From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org> on behalf of Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Thursday, April 12, 2018 2:13 PM
To: openc2-actuator@lists.oasis-open.org
Subject: [openc2-actuator] Firewall Profile: Duration option and persistent option

 

All,

QUESTION ONE:  Are you OK with the following three table entries to cover these temporal attributes?  If not, please provide your reasons and/or alternate text. 

start-time
Required
The time when the allow is to take effect. Date Time data format. 
 
end-time
Required
The time when the allow rule is to be removed.

duration
Optional
The amount of time after the start-time for the allow to be in effect [=] seconds.  In the absence of the start-time option, the duration starts from the time the command is processed.  In the event of a conflict the end-time option (if present) takes precedence. 

--NO, I think as this is laid out it has some logic problems and we will have some issues with timezones. I prefer the idea of start-time=now() along with duration=X seconds as it addresses both of these problems. My thought is that we will have different devices in different timezones even within an org.

 

QUESTION TWO:  Are you OK with the following two table entries to cover running vs persistent?  If not, please provide your reasons and/or alternate text. 

Running
Required
Setting to TRUE results in an ephemeral allow, i.e. the traffic will be allowed while the firewall is operating, but in the event of a restart, power down or recovery, the allow rule will not be  retained. Default value is FALSE.

Persistent
Required
Setting to TRUE results in a permanent rule that will be retained in the event of a restart of power down.  Default value is TRUE

-- I am in the group that doesnt see a lot of value to this, so NO for me. I understand there are some differences, but I am not sure how much it matters or if it just makes this all more complicated. I think we just need to leave this question up to the device that is doing it or whoever write the actual code to implement.


BACKGROUND: 
Normally I would have a one to one relationship between topics and email threads, but one of our colleagues provided a really nice use case to illustrate the point. 
Everyone agreed with the notion that 'start-time' is a useful command option.  Initially, I thought that we would have either 'stop-time' or 'duration' but did not want to have both.  My logic or lack thereof was that you could communicate the same effect with either and wanted to avoid a situation where the same command could be sent in multiple ways.  Based on the discussion we had at the last AP SC meeting, we should include both and state within the specification preferred mechanisms and how to resolve conflicts (if any)

The 'persistent' vs 'running' discussion branched.  There was one school of thought that it should not be included at all.  There was another set of people that considered 'persistent' to be default and 'running' an option (and vice versa).  It was my interpretation of the meeting that we had (weak) consensus for making both of the options mandatory to implement and persistent as the 'default'.   The consensus was weak in this matter, so please do violence with your red pens. 

REALLY NICE USE CASE: 
I can't take credit for this.  One of our colleagues reached out to me out of band and I will respect his anonymity.  Having said that, here is his use case that illustrates the utility of duration and running: 

" I'll add a sample scenario where this could be useful.

Enterprise blasts out a firewall rule to block all outbound traffic to the internet but not internal systems.

Start-Time: 04/10/2018 00:00:00
End-Time: 04/12/2018 00:00:00
Duration: 600 seconds
Running: TRUE

When a vulnerable endpoint comes online, they almost immediately check in to their management system. At the point of checkin, the endpoint receives the OpenC2 command.
For the next 600 seconds, the computer will be unable to reach the internet, only internal resources. During this bootup block, the computer begins its update procedures and gets its software up to date using internal patching software. After the 600 seconds the user is able to surf.

The OpenC2 admin can further define if this openc2 command should continue to be in effect for subsequent reboots based on whether or not the system is patched."


 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]