[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [openc2-actuator] RE: [Non-DoD Source] Re: [openc2-actuator] Modification to the stateless-packet-filter profile
Thank you for the response, but need you to clarify something for me. When we get to ‘deny’ are you suggesting that I repeat all the specifiers that were identified with ‘allow’ (in the interest of being boring and complete) or is OK to replace the duplicates with the phrase:
TO be consistent with the language spec, we need to say either:
“Implementation of the Allow ip-connection command is required” OR
“Implementation of the Allow ip-connection action-target pair is required”
Sound logical?
VR
Joe B
From: openc2-actuator@lists.oasis-
open.org <openc2-actuator@lists.oasis-open.org > On Behalf Of Dave Lemire
Sent: Tuesday, April 3, 2018 2:50 PM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Cc: openc2-actuator@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [openc2-actuator] Modification to the stateless-packet-filter profile
Joe,
1) Yes, I think this is a very logical approach. Nice work.
2) I get that the Deny table is a boring match to the Allow table, but ultimately I think you have to have it. Standards documents thrive on boring completeness.
3) I suggest one modification in your detailed subsection:
2.2.1.1 Allow ip-connection
Implementation of the Allow ip-connection command-target pair is required.
The subsections are describing a command-target pair, not just a command, and I think should be described as such.
Dave
David P. Lemire, CISSP
OpenC2 Technical Committee Executive Secretary
OpenC2 Implementation Considerations SC Co-chair
Contractor support to NSA
Email: dave.lemire@g2-inc.com
Office: 301-575-5190 / Mobile: 240-938-9350
On Mon, Apr 2, 2018 at 2:26 PM, Brule, Joseph M <jmbrule@radium.ncsc.mil> wrote:
All,
Here is my attempt at the language binding in the stateless packet filter profile (located at https://docs.google.com/
document/d/ )1CvD4dhnGPsYVYrMoJTIjeQA9vN3i3 3eqwkhEGRWsBVA/edit#
First I cooked up a matrix of the actions and targets.
Domain-name
ip-connection
ip-addr
hostname
File
OpenC2
x-config
allow
opt
required
required
opt
deny
opt
required
required
opt
query
required
set
opt
opt
update
opt
delete
opt
save
opt
opt
start
stop
restart
Then I created a subsection for each cell that was populated. For example:
2.2.1.1 Allow ip-connection
Implementation of the Allow ip-connection command is required. The command permits traffic that is consistent with the specified ip-connection. A valid allow ip-connection command has at least one property of the ip-connection populated and may have any combination of the five properties populated. An unpopulated property within the the ip-connection target must be treated as an ‘all’. NOTE TO SELF, ASK THE FIREWALL GUYS Table 2.1.1.1 summarizes the allow ip-command as refined by one or more options.
Option
Implement
Description/ effect
response
required
Indicates the type of response required from the firewall. Valid response types are Ack, Complete and None. The default is none.
start-time
required
Self explanatory
end-time
required
Self explanatory
respond-to
optional
Identifies where the firewall is to send its response. QUESTION; CAN THIS BE MORE THAN ONE ENTRY?
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
interface
required
Possible settings are ingress, egress or both. Default is both. Ingress applies the allow to incoming traffic only. Egress applies to outbound.
Then I did the same for the other targets for allow.
For deny, I admit I got kind of lazy, but there was so much repetition, it looked stupid, so I did this:
2.2.2 Deny
Deny can be treated as mathematical complement to allow. With the exception of three additional options outlined in table 2.1.2, the targets, specifiers, modifiers and corresponding responses are identical to the four allow commands.
Option
Implement
Description/ effect
Drop
Required
Traffic meeting the criteria of the target specifier(s) is dropped with no other processing. Default is Drop
Reject
required
Traffic meeting the criteria of the target specifier(s) is dropped and an ICMP host unreachable (or equivalent) is sent to the source address
complete
optional
Traffic meeting the criteria of the target specifier(s) is dropped and receipt of the packet is sent to the source address, i.e. a false acknowledgement
Does this seem like a logical approach?
Thank oyu and please advise
VR
Joe Brule
-----Original Message-----
From: Brule, Joseph M
Sent: Thursday, March 29, 2018 2:19 PM
To: 'openc2-actuator@lists.oasis-open.org ' <openc2-actuator@lists.oasis-open.org >
Subject: This is a mirror of a slack message I sent some moments ago
All,
During yesterday's actuator profile SC meeting, another approach was suggested. The short version of the approach was kind of a nested loop:
For each OpenC2 action applicable to the firewall profile:
For each OpenC2 target type applicable to that action:
Describe what the action will do
Describe the meaning of each applicable option/specifier Provide sample commands
The basic idea was:
Stating whether or not an action or target is mandatory, optional or even meaningful is not practical unless you have the action in the context of the specified target, so address each command holistically rather than work each component of the command.
That was really logical, and I attempted to implement the idea but to be quite blunt with you, I am NOT pleased with my effort. When you get a chance, take a look at https://docs.google.com/
document/d/ , especially look at section 2.2.1CvD4dhnGPsYVYrMoJTIjeQA9vN3i3 3eqwkhEGRWsBVA/edit#heading=h. 8mqj73xx8y2t
Give me more than a 'it is bad' (I already know that). If you can send me a sample write up, do it in the googledoc, create your own googledoc, put it in an email or whatever. I just need some help on it.
Thank you
VR
Joe B
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]