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

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

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


  


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